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ABSTRACT 


Over  the  past  decade,  changes  in  the  global  power  structure  have  driven  the  United 
States  into  a  major  reassessment  of  its  force  structure  and  global  force  projection 
requirements.  There  is  a  resulting  need  for  force  deployment  models  that  offer  quick, 
accurate  analysis  of  force  projection  options  and  proposed  force  structure  changes.  One 
model,  the  Force  Deployment  Estimator  (FDE),  a  combination  discrete  event  simulation 
and  goal  program,  is  currently  used  by  the  J8,  Warfighting  Analysis  Division  (J8/WAD).  A 
second  model  with  similar  capabilities,  the  Naval  Postgraduate  School  /  RAND  Mobility 
Optimizer  (NRMO),  is  a  linear  program  that  was  written  for  the  Air  Force  Studies  and 
Analysis  Agency.  In  order  to  compare  the  two  models  and  give  J8/WAD  the  option  of  a 
second  model  for  use  in  analysis,  NRMOAS  (NRMO  Air/Sea)  was  created  by  adding  a 
sealift  component  to  NRMO.  NRMOAS  creates  both  an  air  and  sea  network  and  can  be  run 
with  the  user  designating  the  unit’s  mode  of  travel,  the  model  determining  the  same  or  a 
combination  of  both.  This  thesis  compares  the  results  of  several  different  scenarios  ran 
through  FDE  and  NRMOAS.  In  all  cases  tested,  NRMOAS  out-performed  FDE  in  terms  of 
timely  delivery  of  personnel  and  cargo.  Additionally,  NRMOAS  allows  a  far  higher  level  of 
resolution  in  network  structure.  Recommendation  to  J8/WAD  is  that  NRMOAS  be  used  for 
detailed  mobility  analysis.  Also  recommend  are  changes  to  FDE  to  improve  its  usefulness. 
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EXECUTIVE  SUMMARY 


Over  the  past  decade,  changes  in  the  global  power  structure  have  driven  the  United 
States  into  a  major  reassessment  of  its  force  structure  and  global  force  projection  requirements. 
Numerous  studies  have  established  a  need  for  models  that  are  flexible,  and  can  offer  quick, 
accurate  analysis  of  force  projection  options  and  proposed  force  structure  changes.  The  J-8, 
Warfighting  Analysis  Division  (J-8/WAD)’s  current  tool  for  analyses  of  this  nature  is  the  Force 
Deployment  Estimator  (FDE),  a  combination  discrete  event  simulation  and  goal  programming 
model  provided  by  SETA  Corporation.  Because  FDE  does  not  achieve  optimal  solutions  and  it 
sometimes  does  not  complete  execution,  it  is  desirable  for  J-8/WAD  to  have  a  second  model  to 
compare  against  FDE. 

The  Naval  Postgraduate  School  /  RAND  Mobility  Optimization  model  (NRMO),  a 
linear  optimization  model  that  considers  airlift  only,  has  many  similar  capabilities  to  FDE.  The 
purpose  of  this  thesis  is  to  make  a  comparison  of  the  two  and  recommend  to  J8/WAD  which 
one  better  suits  their  needs.  In  order  for  NRMO  to  be  useful  to  J-8/WAD  and  comparable  to 
FDE,  it  must  also  handle  sealift.  This  additional  capability  required  several  augmentations  to 
the  existing  NRMO  model,  which  are  developed  in  this  thesis.  The  result  is  the  Naval 
Postgraduate  School  /  RAND  Mobility  Optimizer,  Air  /  Sea  (NRMOAS),  a  version  of  NRMO 
that  allows  the  model  to  conduct  both  airlift  and  sealift  operations.  In  order  for  NRMOAS  to  set 
up  both  an  air  and  sea  network,  it  was  necessary  to  add  sets  to  distinguish  airfields  from  ports, 
aircraft  from  ships  (referred  to  jointly  as  “vehicles”),  and  air  ports  of  embarkation  (APOEs) 
from  seaports  of  embarkation  (POEs).  These  additions  also  required  the  separation  of  the 
variables  used  to  make  initial  allocation  of  vehicles.  Once  initially  allocated,  ships  travel  only 
on  sea  routes  and  aircraft  only  on  air  routes,  so  all  other  constraints  can  be  used  by  both  aircraft 
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and  ships  without  fear  of  redundant  or  conflicting  use  of  assets.  Other  changes  that  were 
required  dealt  with  port  capacity  and  fuel  consumption  constraints.  In  addition,  J-8AVAD 
required  that  the  model  allow  the  user  to  track  the  by-day  delivery  of  every  unit’s  cargo  and 
personnel.  This  calculation  was  added  to  NRMO.  Values  for  ship  speed,  capacity,  load  and 
unload  times  and  fuel  consumption  were  taken  directly  from  FDE.  Where  information  was 
unavailable,  it  was  developed  from  military  manuals,  phone  calls  and  existing  data  sets. 
NRMOAS  operates  with  two  types  of  travel  mode  selection:  user  designated  and  model 
designated.  This  required  the  compilation  of  aircraft  /  ship  load  tables  that  were  a  composite  of 
those  found  both  in  NRMO  (units  by  air  only)  and  FDE  (units  by  air  or  ship,  but  not  both). 

Once  developed,  three  scenarios  were  run  through  NRMOAS  and  FDE.  FDE  was 
extremely  challenging  to  work  with  and  demonstrated  several  major  restrictions  in  its  ability  to 
represent  an  actual  network.  Paths  with  more  than  four  links  are  not  tolerated  by  the  model, 
making  accurate  depiction  of  deployment  networks  virtually  impossible.  Similarly,  scenarios 
with  a  large  number  of  source  nodes  aand  a  small  amount  of  cargo  caused  FDE  to  crash. 
Difficulties  were  also  encountered  building  the  FDE  data  sets.  In  most  caes,  FDE  files  are  built 
using  a  legacy  file  which  contains  extensive  unit  and  carrier  information.  This  file  serves  as  a 
shell  from  which  desired  scenarios  are  built.  Building  files  from  scratch  is  extremely 
challenging  and  is,  in  fact,  highly  discouraged  by  experienced  FDE  users.  Specific  problems 
include:  FDE’s  inability  to  utilize  a  path  that  has  any  more  than  four  links,  and  FDE’s  inability 
to  handle  a  network  designed  with  multiple  source  nodes  and  small  amounts  of  cargo. 
Eventually,  data  was  sent  to  a  SETA  analyst  who  built  the  closest  representation  of  the  desired 
deployment  network  that  could  be  designed.  Once  FDE  was  running,  no  more  than  26  trial 
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solutions  could  be  requested  for  any  problem.  Any  number  higher  than  that  again  caused  the 
model  to  crash. 

Once  results  were  obtained  from  FDE,  comparison  were  made  between  the  two  models. 
NRMOAS  out-performed  IDE  in  terms  of  timely  delivery  of  cargo  and  personnel  in  all  runs. 
Totaling  the  units  from  all  three  scenarios,  NRMOAS  delivered  67.7%  of  unit  cargo  and  65.1% 
of  unit  personnel  on-time  compared  to  FDE’s  44.00%  for  unit  cargo  and  41.3%  for  unit 
personnel.  NRMOAS  also  achieved  a  high  on-time  delivery  rate  of  95.8%  for  unit  cargo  and 
100.0%  for  unit  personnel  compared  to  FDE’s  highs  of  70.8%  and  80.3%,  respectively. 
NRMOA’s  superior  performance  was  attributed  to  better  utilization  of  assets  available. 

There  are  two  final  conclusions.  First,  if  FDE  is  to  be  retained  as  a  tool  for  analysis  in 
J8/WAD,  it  requires  major  improvements  in  its  ability  to  accurately  represent  deployment 
networks.  The  initial  allocation  algorithm,  the  graphical  user  interface  and  the  extreme 
difficulty  in  building  files  from  scratch  must  also  be  addressed.  The  second  conclusion  is  that 
NRMOAS ’s  superior  performance  and  higher  level  of  resolution  for  networks  and  infrastructure 
make  it  a  better  tool  for  analysis  than  FDE.  Recommendation  to  J8/WAD  is  that  NRMO  be 
adopted  as  their  main  tool  for  detailed  analysis,  while  FDE  can  be  used  for  broad  brush  mobility 
questions  that  don’t  require  a  high  degree  of  network  resolution. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Over  the  past  decade,  changes  in  the  global  power  structure  have  driven  the  United 
States  into  a  major  reassessment  of  its  force  structure  and  global  force  projection  requirements. 
The  Mobility  Requirements  Study  (MRS)  of  1990,  the  MRS  Bottom  Up  Review  Update  (MRS 
BURU)  of  1992,  the  Quadrennial  Defense  Review  of  1996,  and  numerous  other  smaller,  more 
limited  studies,  have  established  a  need  for  models  that  can  offer  quick,  accurate  analysis  of 
force  projection  requirements  and  proposed  force  structure  changes.  Because  these  taskings  can 
run  the  gamut  from  major  force  deployment  studies  of  the  magnitude  of  DESERT  SHIELD  / 
DESERT  STORM  to  the  effects  of  adding  to  or  deleting  strategic  lift  capabilities,  the  required 
models  should  be  flexible. 

B.  PROBLEM  STATEMENT 

The  J-8  (Force  Structure,  Resources  and  Assessment)  section  of  the  Joint  Chiefs  of  Staff 
is  often  tasked  with  conducting  these  types  of  studies.  Within  the  J-8,  these  taskings  normally 
fall  to  the  Warfighting  Analysis  Division  (J-8/WAD).  In  most  cases,  J-8/WAD  is  concerned 
with  the  following  general  types  of  questions: 

1.  How  long  will  it  take  to  get  units  and  cargo  to  the  Area  of  Operations? 

2.  What  is  the  most  efficient  use  of  the  assets  available? 

3.  What  is  the  affect  of  changes  in  specific  assets? 

4.  What  is  the  affect  of  changes  in  infrastructure? 
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J-8/WAD’s  current  tool  for  analyses  of  this  nature  is  the  Force  Deployment  Estimator  (FDE) 
(FDE  URM,  1996),  provided  by  SETA  Corporation.  FDE  combines  a  discrete  event  simulation 
and  goal  programming  model.  It  is  used  both  to  generate  force  arrival  profiles  and  to  conduct 
sensitivity  analysis  on  the  results.  Because  FDE  does  not  achieve  optimal  solutions  and  it 
sometimes  does  not  complete  execution,  it  is  desirable  for  J-8/WAD  to  have  a  second  model  to 
compare  against  FDE.  The  Naval  Postgraduate  School  /  RAND  Mobility  Optimization  model 
(NRMO)  (Melody,  et  al,  1997)  is  a  linear  optimization  model  that  considers  airlift  only.  With 
the  addition  of  a  sealift  component,  NRMO  could  offer  J-8/WAD  a  viable  alternative  to  FDE. 
The  purpose  of  this  thesis  is  to  add  a  sealift  component  to  NRMO,  compare  that  model  with 
FDE  and  make  a  recommendation  to  J-8/WAD  as  to  which  model  better  suits  their  needs. 
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II.  MODEL  REVIEW 


A.  FORCE  DEPLOYMENT  ESTIMATOR 

1.  Overview 

The  Force  Deployment  Estimator  (FDE)  is  designed  to  provide  quick  analysis  of 
deployment  and  sustainment  issues  as  they  relate  to  contingency  plans  (FDE  URM,  1998,  p.  1- 
1).  Specifically,  it  is  designed  to  answer  the  following  questions: 

a.  Can  the  forces  be  deployed  to  the  theater  on  time  (as  defined  by  the  required 
delivery  date)?  If  not,  how  close  can  they  get? 

b.  What  are  the  most  likely  arrival  times  for  forces? 

c.  What  are  the  most  important  factors  contributing  to  the  arrival  times  for  the  forces? 

d.  How  will  the  answers  to  the  above  questions  change  if  the  theater  deployment  is 
delayed  by  late  availability  of  units  or  lift  assets;  by  enemy  attacks  on  ports  or 
airfields;  or  by  closure  of  vital  choke  points  such  as  straits,  canals,  or  shipping  lanes 
caused  by  enemy  minefields?  (FDE  URM,  1998,  p.  3-1) 

FDE  allows  sensitivity  analysis  over  a  variety  of  issues.  By  varying  input,  users  can 
parametrically  assess  a  war  plan  with  respect  to  variations  in  force  structure,  lift  capabilities, 
phasing  of  units  and  any  number  of  questions  that  arise  during  force  structure  analysis. 

2.  History 

FDE  1.0  was  developed  by  Los  Alamos  National  Laboratory  and  released  in  April  of 
1992.  Originally  written  in  FORTRAN,  it  underwent  its  first  major  overhaul  by  Potomac 
Systems  Engineering  and  was  released  as  FDE  2.0  in  September  of  1994.  FDE  2.0  added 
stochastic  loading  time  variables  in  an  effort  to  make  a  more  realistic  appraisal  of  deployment 
requirement  times.  The  next  upgrade,  FDE  3.0,  was  released  by  SETA  Corporation  in  October 
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of  1996.  FDE  3.0  is  a  major  revision,  including  conversion  to  C++  and  the  addition  of  a 
graphical  user  interface.  SETA  also  advertised  that  FDE  3.1  would  contain  a  simulated 
annealing  capability.  This  capability  was  supposed  to  yield  a  5  to  20  times  increase  in  run  time 
and  to  provide  globally  optimal  solutions  (FDE  URM,  1998,  p.  3-9).  FDE  3.1  was  released  in 
April  of  1998,  but  did  not  contain  the  simulated  annealing  capability  and  in  fact  showed  no 
significant  difference  from  version  3.0.  It  does  not  provide  global  optima.  FDE  3.1  is  the 
version  that  will  be  used  for  comparison  with  NRMO. 

3.  Features 

FDE’s  primary  function  is  the  efficient  assignment  of  lift  platforms  for  deployment  and 
sustainment  of  units,  in  support  of  war  plans.  Assignment  of  cargo  to  carriers  and  carriers  to 
routes  is  made  within  the  constraints  set  by  the  user.  The  model  “solves”  the  problem  based  on 
four  specific  goals: 

1.  Minimize  closure  time  deviations  for  units.  (Closure  time  deviation  is  defined 
as  the  number  of  days  after  the  required  delivery  date  (rdd)  that  a  unit  arrives 
in  theater.) 

2.  Minimize  the  dispersion  of  delivery  times  for  each  unit.  (Dispersion  is 
defined  as  the  time  between  consecutive  deliveries  of  a  unit’s  cargo  and 
personnel.) 

3.  Minimize  the  cost  of  the  deployment.  (An  actual  dollar  value  for  operation  of 
each  type  of  lift  asset  can  be  added  to  the  problem.) 

4.  Minimize  the  number  of  carrier  reallocations.  (Lift  assets  are  initially 
allocated  at  random  or  are  assigned  to  specific  bases  by  the  user.  They  are 
“re-allocated”  if  they  must  be  moved  empty  from  one  embarkation  base  to 
another  during  the  execution  of  the  simulation.) 

These  goals  may  be  used  singly  or  in  any  combination,  as  specified  by  the  user.  If  no  goal  is 
specified,  FDE  takes  the  first  goal  as  the  default.  (FDE  URM,  1998,  p.  3-4) 
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FDE’s  methodology  can  be  described  as  a  combination  of  discrete  event  simulation,  goal 
programming  and  Monte  Carlo  search  techniques  (FDE  URM,  1998,  p.  3-1).  The  discrete  event 
simulator  is  the  portion  of  code  that  “executes”  the  deployment.  The  goal  program  is  not  an 
actual  goal  program,  as  defined  in  the  linear  programming  literature  [Dantzig  and  Thapa,  1997], 
but  simply  a  method  to  check  the  solution  to  see  if  it  meets  the  goals,  as  selected  by  the  user. 
The  simulation  runs  as  many  times  as  the  user  specifies,  saves  all  the  solutions  and  then  picks 
the  “best”  one,  in  terms  of  meeting  the  user  defined  goals.  The  URM  states  that  the  solution 
will  be  a  local,  but  not  necessarily  global  optimum  (FDE  URM,  1998,  p.3-6).  There  is  no 
substantiation  to  this  claim. 

4.  Organization 

FDE  is  organized  into  three  main  components:  a  data  management  facility,  a  modeling 
kernel  and  a  graphical  user  interface  (FDE  URM,  1998,  p.  2-3). 

The  data  management  facility  is  composed  of  a  large  internal  data  file  and  numerous  output 
files.  To  operate,  FDE  requires  input  from  formatted  data  files.  These  can  be  generated  from 
the  internal  data  file  or  input  via  the  graphical  user  interface.  The  internal  data  file  contains 
legacy  files  called  “fort.l”  files.  These  files  have  been  developed  over  time  and  contain  large 
amounts  of  data  related  to  unit  loading  requirements  and  cargo  carrier  capacity.  The  “fort.l” 
files  can  be  used  as  a  starting  point  from  which  to  build  current  data  sets,  with  additional 
required  elements  input  via  the  GUI.  The  ten  output  files  are  written  in  two  formats:  reports 
and  graphs.  Specific  output  file  information  is  shown  in  Appendix  A.  (FDE  URM,  1998,  p.  2- 
2) 

The  modeling  kernel  contains  the  actual  mathematical  algorithms  used  to  solve  the 
problem.  It  has  three  main  components;  the  discrete  event  simulator,  the  so  called  goal 
programming  model  and  a  Monte  Carlo  simulation. 
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The  discrete  event  simulation  is  the  core  of  FDE  and  actually  “executes”  the  deployment 
simulation.  The  simulation  itself  contains  four  major  algorithms.  The  first  algorithm  makes  the 
initial  assignments  of  carriers  to  units.  This  is  done  in  direct  proportion  to  the  tonnage 
requirements  of  the  unit  and  in  inverse  proportion  to  the  square  of  the  product  of  the  unit 
priority  and  required  arrival  date,  while  also  considering  what  types  of  cargo  the  carrier  can 
move.  The  user  may  over-ride  this  algorithm  by  pre-assigning  carriers  to  specific  start  points  or 
units.  The  second  algorithm  contains  the  logic  which  re-assigns  carriers  once  they  have 
completed  their  current  delivery.  It  is  similar  in  process  to  the  initial  assignment  algorithm,  so 
the  carrier  will  be  re-assigned  to  the  node  that  needs  it  the  most.  (FDE  URM,  1998,  p.  3-16) 

The  third  algorithm  is  the  aircraft  loading  algorithm.  This  algorithm  considers  five 
separate  loading  cases,  based  on  allowable  load  combinations  and  aircraft  capacity.  The  amount 
of  personnel  or  cargo  an  aircraft  can  carry  is  determined  from  load  factors  designed  by  the  US 
Air  Force  Studies  and  Analyses  Agency  for  the  MIDAS  model  (FDE  URM,  1998,  p.  3-16).  The 
algorithm  also  accounts  for  the  amount  of  cargo  and  personnel  moved  throughout  the 
simulation.  Algorithm  specifics  are  shown  in  Appendix  A. 

The  final  algorithm  is  the  ship  and  rail  loading  algorithm.  The  actual  logic  used  in  this 
algorithm  comes  from  the  Carrier  Payload  tables  in  the  FDE  database.  Once  the  algorithm 
determines  whether  the  carrier  in  question  is  a  ship  or  train,  it  checks  to  see  if  the  cargo  that  is 
available  to  be  loaded  is  greater  than  or  equal  to  the  carrier’s  capacity,  as  measured  in  tons  of 
cargo  per  unit  type.  If  so,  the  carrier  is  loaded  until  full  and  it  departs  for  its  destination.  If  not, 
the  carrier  loads  all  available  cargo  and  the  model  looks  for  any  other  cargo  enroute  to  the  same 
destination.  If  such  cargo  exists,  the  carrier  waits  until  this  cargo  is  delivered  and  loaded.  If 
not,  the  carrier  departs.  (FDE  URM,  1998,  p.  E-l) 
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The  modeling  kernel  also  contains  the  goal  programming  algorithm.  What  FDE  calls  a 
goal  programming  algorithm  is  not  an  actual  goal  program  as  defined  in  linear  programming 
literature.  (FDE  URM,  1998,  p.  3-6)  In  actuality,  it  simply  takes  the  current  solution  and 
compares  it  against  the  “best”  solution  found  to  that  point,  in  terms  of  meeting  the  user  defined 
goals.  If  the  new  solution  comes  closer  to  meeting  these  goals,  it  becomes  the  new  “best” 
solution.  The  URM  is  not  specific  about  how  this  comparison  takes  place.  Following  the 
comparison,  the  program  checks  to  see  if  the  simulation  should  be  run  again,  based  on  a  user 
defined  number  of  iterations.  This  continues  until  the  required  number  of  simulations  has  been 
completed.  A  better  name  for  the  FDE  goal  programming  module  would  be  a  “goal  evaluator”. 

The  final  part  of  the  modeling  kernel  is  the  Monte  Carlo  simulation,  which  randomly 
allocates  carriers  to  specific  nodes  and  paths  throughout  the  network.  This  is  repeated  at  the 
start  of  every  run  of  the  simulation.  The  number  of  desired  simulation  runs  is  set  by  the  user. 
SETA  advertises  that  if  the  number  of  runs  is  sufficiently  large  (i.e.  25  to  75),  the  results  will  be 
very  close  to  a  global  optimal.  (FDE  URM,  1998,  p.  3-9)  No  substantiation  to  this  statement  is 
offered.  This  would  be  a  unique  result  in  the  operations  research  literature  if  it  were  proven. 

The  graphical  user  interface  ties  the  data  and  related  file  utilities  to  the  modeling  kernel 
(FDE  URM,  1998,  p.  2-3).  It  is  a  standard  Windows-based  product,  with  five  types  of 
windows.  The  main  window  appears  when  the  program  is  started  and  is  the  window  through 
which  all  other  windows  are  started  and  accessed.  Dialog  windows  provide  secondary  interface 
with  FDE  and  appear  over  the  main  window.  File  selection  windows  allow  the  user  to  select 
specific  files  from  various  directories  and  sub-directories.  Selection  windows  are  contained 
within  other  windows  and  allow  the  user  to  make  selections  from  lists  of  choices  contained  in 
the  window.  Finally,  message  windows  are  used  to  send  messages  to  the  reader.  They  include 
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information  dialog,  question  dialog,  working  dialog  and  warning  dialog.  (FDE  URM,  1998,  p. 
4-4) 

5.  Hardware 

FDE  was  designed  and  tested  to  run  on  a  SUN  SPARC  system.  Currently,  J-8AVAD 
runs  FDE  on  SUN/UNIX  work  stations,  but  it  can  also  run  on  stand-alone  units.  It  requires  1.3 
gigabytes  of  hard  disk.  In  addition,  300  megabytes  of  swap-space  is  recommended  to  allow 
FDE  to  build  temporary  matrices  when  solving  problems,  for  a  total  requirement  of  1.6 
gigabytes.  FDE  requires  no  additional  software.  (FDE  URM,  1998,  p.  2-3) 

6.  Assumptions  and  Restrictions 

FDE’s  documentation  includes  fourteen  stated  assumptions.  The  most  critical 
assumption  is  that  FDE  is  designed  as  an  operational  planning  tool  and  not  as  a  logistics 
planner.  The  logistics  planning  factors  are  sufficient  to  answer  force  deployment  questions,  but 
not  detailed  logistical  questions.  In  particular,  a  high  level  of  aggregation  of  unit  cargo  and  base 
infrastmcture  would  make  FDE  ineffective  as  a  logistical  planning  tool.  Moreover,  FDE  is 
designed  to  analyze  initial  deployments,  defined  as  activity  prior  to  the  establishment  of  a 
logistics  pipeline.  During  the  initial  phase,  deploying  units  and  sustainment  requirements 
compete  for  assets  equally.  FDE  assumes  that  once  a  logistics  pipeline  is  established, 
sustainment  will  no  longer  be  required  to  compete  for  assets,  but  will  have  specific  assets 
dedicated  to  its  movement  (FDE  URM,  1998,  p.  3-2).  Additional  assumptions  deal  with 
modeling  issues  and  are  listed  in  Appendix  A. 

J-8  imposed  three  restrictions  on  the  designers  of  FDE.  First,  given  a  scenario  and  the 
input,  FDE  must  run  in  under  30  minutes.  (This  restriction  was  non-specific  as  to  the  platform 
used  or  the  number  of  simulation  runs  required.)  Second,  all  events  that  take  place  during  the 
simulation  must  be  physically  realistic.  For  example,  a  shipping  route  cannot  cross  a  land  mass. 
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but  must  navigate  around  it.  Finally,  the  model  must  be  “user-friendly”.  (FDE  URM,  1998,  p. 

3-2) 

7.  Input 

FDE  categorizes  scenario  information  into  five  parts,  which  are  defined  below: 

a.  Lift  Assets  (Carriers).  These  are  defined  as  those  items  that  can  transport  personnel 
and/or  cargo  from  port  to  port.  FDE  lift  assets  include  aircraft,  shipping,  trucks  and 
trains.  Lift  asset  information  includes  average  speed  and  capacity,  broken  down  by 
cargo  types. 

b.  Deployment  Requirements.  These  include  the  actual  units,  their  equipment, 
destination,  point  of  origin,  date  available  to  move,  required  delivery  date  and  unit 
priority. 

c.  Network.  This  is  the  node-arc  network  of  routes  available  for  the  deployment.  Nodes 
are  defined  by  longitude  and  latitude,  carrier  types  that  can  use  them  and  carrier 
capacity.  Arcs  are  defined  by  the  nodes  they  connect  and  the  carriers  that  can  travel 
on  them. 

d.  Goals.  These  are  defined  by  the  user  and  were  listed  earlier.  Any  combination, 
including  all  four,  can  be  selected. 

e.  Constraints.  These  are  derived  from  the  scenario.  They  include  items  such  as 
availability  of  assets  or  restrictions  on  certain  carrier/cargo  combinations,  barriers  to 
carrier/path  combinations  or  degradation  of  certain  nodes  or  arcs  due  to  enemy 
activity.  Route  or  node  degradation  is  provided  as  user  inputs. 

(FDE  URM,  1998,  p.  3-3) 


9 


*  Not  Implemented 

Figure  1.  This  flow  diagram  depicts  the  primary  modules  of  the  solution  algorithm.  This 
methodology  is  not  a  single  program,  but  rather  a  series  of  three  techniques  that  work  together 
until  one  of  three  things  happens:  a  feasible  solution  is  achieved,  the  model  “cut-off’  criterion  is 
reached,  or  a  specific  number  of  solutions  are  generated  (FDE  URM,  1998,  p.  3-5). 


8.  Solution  Method 

The  solution  method  uses  three  separate  mathematical  techniques  that  interact  iteratively 
(FDE  URM,  1998,  p.3-5).  This  method  is  pictured  in  Figure  1.  When  solving  the  problem, 
FDE  first  determines  if  there  is  a  feasible  solution  to  the  allocation  of  lift  to  satisfy  all  the  goals. 
If  not,  FDE  will  allocate  assets  to  achieve  a  solution  that  is  as  close  to  feasible  as  possible,  i.e. 
the  “best”  possible  solution  (FDE  URM,  1998,  p.  3-1).  FDE  can  be  used  in  either  a  simple  or  a 
variable  mode. 
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The  simple  mode  is  the  most  commonly  used.  Input  values  such  as  speed,  carrier 
capacity,  etc.  are  fixed  at  their  expected  value.  The  program  runs  a  user  defined  number  of 
trials  and  the  solution  which  comes  closest  to  meeting  the  user  defined  goals  is  given.  Simple 
mode  is  normally  used  when  trying  to  answer  the  question,  “Can  forces  be  deployed  to  the 
theater  on  time?”  or  “What  is  the  most  likely  theater  deployment  time?”  (FDE  URM,  1998,  p. 
3-10) 

In  the  variable  mode,  the  user  chooses  both  the  number  of  simulation  runs  and  the 
number  of  trials  within  each  run.  First,  the  model  finds  a  run’s  “best”  solution.  Then  it 
conducts  sensitivity  analysis  on  this  solution  by  drawing  a  value  for  each  variable  from  a  given 
probability  distribution  and  running  the  solution  with  that  data.  This  “draw  and  solve”  cycle  is 
repeated  for  whatever  number  of  trials  the  user  chooses.  The  model  then  performs  an  Analysis 
of  Variance  (ANOVA)  on  these  results  and  gives  each  solution’s  mean,  variance  and  most 
likely  result.  FDE  URM,  1998,  p.  3-1 1) 

9.  Results 

Results  from  FDE  can  be  used  either  in  a  report  or  graphical  format.  FDE’s  results  are 
most  commonly  used  to  answer  the  four  questions  that  were  stated  at  the  beginning  of  the 
section  on  FDE.  In  addition,  sensitivity  analysis  can  easily  be  carried  out  by  varying  input 
parameters  and  observing  how  that  changes  results.  Analysis  of  this  type  can  then  be  used  to 
gain  insight  into  force  structure  questions  from  a  force  deployment  standpoint.  For  example, 
questions  such  as  increasing  or  decreasing  the  number  of  a  certain  type  of  carrier  or  heavy 
versus  light  divisions  can  be  considered  with  an  eye  towards  their  effect  on  the  United  States’ 
ability  to  deploy  its  forces  abroad  with  a  given  fleet  of  lift  assets.  FDE  can  also  be  used  to 
“wargame”  deployment  plans  and  determine  how  the  loss  or  addition  of  assets  will  affect  these 
plans. 
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B.  NAVAL  POSTGRADUATE  SCHOOL  /  RAND  MOBILITY  OPTIMIZER 
(NRMO) 

1.  Overview 

NRMO  was  designed  to  help  planners  and  analysts  answer  the  airlift  force  structure  and 
infrastructure  questions  that  are  associated  with  force  deployment  issues.  Typical  of  these  types 
of  questions  are: 

a.  Are  the  given  fleet  and  infrastructure  assets  adequate  for  deployment? 

b.  Where  are  the  system  bottlenecks?  When  do  they  matter?  How  much  do  they  limit 
airlift  capacity? 

c.  What  changes  in  mobility  concepts  of  operation  would  improve  performance?  What 
about  the  affects  of  reduced  closure  time  (defined  as  the  arrival  of  a  unit’s  personnel 
and  cargo)  or  reduced  resource  expenditures? 

d.  How  do  the  results  differ  across  scenarios? 

(Melody,  et  al.,  1997,  p.  v) 

NRMO  has  been  used  to  conduct  airlift  force  structure  analysis,  infrastructure  analysis  and 
concept  of  operations  analysis  using  a  single  model. 

2.  History  and  Genealogy 

Development  of  NRMO  began  in  May  of  1996  as  a  cooperation  between  the  Naval 
Postgraduate  School  (NPS)  and  RAND.  At  that  time,  NPS  was  under  contract  to  the  Air  Force 
Studies  and  Analysis  Agency  (AFSAA)  for  work  in  the  area  of  air  mobility.  RAND,  who  had 
previously  done  a  significant  amount  of  research  in  this  field,  began  their  portion  of  the  work  in 
response  to  a  direct-assistance  request  from  Headquarters,  United  States  Air  Force.  AFSAA 
desired  that  NPS  and  RAND  work  together  in  an  attempt  to  create  a  single  optimization  model 
that  incorporated  all  the  best  features  of  past  models.  NRMO  was  the  result.  The  current  model 
is  under  the  cognizance  of  the  Air  Force  Studies  and  Analysis  Agency  (AFSAA).  In  addition  to 
continuing  research  being  done  by  NPS  and  RAND,  other  users  include  Air  Mobility 
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Command;  Air  Force  Institute  of  Technology;  J-8/Warfighting  Analysis  Division,  JCS;  U.S. 
Air  Force  Academy;  University  of  Texas  at  Austin;  and  Washington  University,  St.  Louis. 

NRMO  can  trace  its  lineage  to  four  main  models;  Mobility  Optimization  Model  (MOM) 
(Wing,  et  al,  1991),  THRUPUT1  (Yost,  1994),  CONOP  (Killingsworth  and  Melody,  1997),  and 
THRUPUT2  (Morton,  et  al,  1996).  MOM,  developed  by  J-8  and  NPS,  incorporated  both  sealift 
and  airlift  in  a  time-dynamic  model  with  a  simple  geographical  network  representation. 
THRUPUT1,  developed  in  1991  by  AFSAA  had  an  extensive  geographical  network,  but  was  a 
steady  state  model.  THRUPUT2,  developed  by  NPS  for  AFSAA  in  1994-5,  combined  the 
dynamics  of  MOM  and  the  extensive  geographic  representation  of  THRUPUT1  into  a  single 
model.  CONOP,  developed  by  RAND  in  1994,  is  a  time-dynamic  model  with  a  robust 
geographical  representation  much  like  THRUPUT2  and  with  features  to  handle  intra-theater 
cargo  lift  and  aerial  refueling.  CONOP  was  used  to  address  force  deployment  policies  relating 
to  tanker  aircraft  and  C-17  usage.  NRMO,  while  developed  and  written  from  scratch,  merged 
many  of  the  techniques  developed  in  the  above  mentioned  models.  (Melody,  et  al,  1997,  p.  5) 
NRMO  and  its  progenitors  are  all  implemented  with  the  Generalized  Algebraic  Modeling 
System  (GAMS).  [Brooke,  Kendrick  and  Meeraus,  1988.] 

3.  Features 

NRMO  is  a  linear  program.  The  objective  function’s  primary  purpose  is  to  maximize 
on-time  deliveries,  air-asset  measures  of  performance  and  ground  assets  measures  of 
perfromance  (Melody,  et  al.,  1997,  p.12).  Mathematically,  this  is  done  through  the 
minimization  of  the  weighted  sum  of  late  and  undelivered  cargo  penalties,  subject  to  restrictions 
such  as  aircraft  balance,  aircraft  payload,  and  airfield  capacity  (Baker,  1997,  p.  55).  There  are 
secondary  terms  in  the  objective  function,  relating  to  preservation  of  assets,  used  to  break  ties 
among  alternate  optima  with  respect  to  the  primary  purpose.  It  can  have  up  to  twenty-seven 
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types  of  decision  variables,  which  it  uses  to  allocate  aircraft  and  crews  among  various  allowable 
options  defined  in  terms  of  load  carried,  route  and  method  of  delivery. 

NRMO’s  many  features  can  be  used  to  represent  the  complexities  of  an  air  mobility 
network  (Melody,  et  al,  1997,  p.10).  NRMO’s  network  representation  allows  for  multiple 
embarkation,  debarkation  and  enroute  airfields,  to  include  use  of  recovery  bases  (bases  where 
aircraft  are  serviced  following  a  quick  tum-around  mission).  NRMO  has  the  ability  to  add 
aircraft  during  the  deployment  period  in  order  to  simulate  the  mobilization  of  assets,  such  as 
Civilian  Reserve  Air  Fleet  (CRAF).  Aircraft  can  be  utilized  in  dual  roles  (ie.  KC-lO’s  can  carry 
cargo  or  perform  aerial  re-fueling)  and  can,  if  needed,  change  roles  during  the  execution  of  the 
model.  In  addition  to  inter-theater  movement,  NRMO  can  move  cargo  via  intra-theater  shuttles. 
NRMO  also  has  the  ability  to  track  the  movement  of  individual  Time  Phased  Force  Deployment 
Data  (TPFDD)  line  numbers.  (Melody,  et  al,  1997,  p.  10) 
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4.  Organization 

NRMO  consists  of  a  GAMS  formulation,  five  input  files  and  an  output  report.  The 
actual  GAMS  code  for  the  original  NRMO  is  not  reproduced  in  this  paper,  but  the  conceptual 
formulation  is  shown  in  Figure  2: 


Maximize:  On-time  Deliveries 

+  air  assets  measure  of  performance 

+  ground  assets  measure  of  performance 

Subject  to: 

Meet  time-phased  demands: 

by  line  id,  cargo  type 

Aircraft  Allocation/balance: 
strategic, 

by  type,  airfield,  for 

. 

tanker,  and  tactical 

missions 

Cargo  Transshipment  balance: 
time 

by  line  id,  cargo  type. 

Cargo/passenger  capacity: 

by  line  id,  aircraft  type, 

time 

Aircraft  utilization  rates: 

by  aircraft  type,  time 

Figure  2.  Conceptual  Formulation  for  NRMO.  Although  the  conceptual  formulization  calls  for 
maximization,  this  is  actually  accomplished  by  minimizing  the  weighted  sum  of  late  and 
undelivered  cargo  penalties  (Melody,  et  al,  1997,  p.  12) 

NRMO’s  five  input  files  contain  all  the  information  required  for  NRMO  to  solve  the 
problem.  Their  contents  are  detailed  in  Appendix  B.  NRMO’s  output  file  is  designed  to  be 
read  as  comma-delineated  input  to  a  spreadsheet.  Its  contents  are  also  detailed  in  Appendix  B. 

5.  Software 

NRMO  uses  the  Generalized  Algebraic  Modeling  System  (GAMS)  [Brooke,  et  al, 
1988].  GAMS  is  a  commercial  programming  language  specialized  for  linear,  integer  and  non¬ 
linear  programming.  It  is  designed  to  allow  models  to  be  solved  on  many  different  types  of 
computers  with  no  formulation  changes.  GAMS  requires  no  special  editor  or  graphical  user 
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interface,  but  instead  can  be  written  using  any  word  processor.  Hardware  specifications  call  for 
2MB  RAM  and  200KB  Real  Mode  Memory  to  run  GAMS,  however  an  average  sized  NRMO 
scenario  (single  MTW)  normally  requires  250  to  300  megabytes  of  memory.  Depending  on  the 
type  of  problem  being  solved,  a  GAMS  user  can  choose  from  multiple  solvers,  seven  of  which 
can  solve  linear  programming  problems. 

6.  Input 

NRMO  works  in  accordance  with  user-set  delivery  windows,  defined  in  the  input  files 
by  available-to-load  dates,  required  delivery  dates  and  maximum  allowable  late  dates.  While 
specific  inputs  will  obviously  vary  from  scenario  to  scenario,  the  following  generic  information 
is  needed  for  NRMO  to  run  a  scenario: 

a.  Unit  Movement  Requirements:  available-to-load  dates,  required  delivery  dates, 
commodity  codes  (a  standard  description  of  generic  unit  types  that  lets  planners  know 
how  much  of  a  certain  type  of  a  specific  unit’s  cargo  an  aircraft  can  carry),  and  the  actual 
number  of  passengers,  and  tons  and  types  of  cargo  that  need  to  be  moved. 

b.  Route  Data:  bases  and  aircraft/route  compatibility. 

c.  Base  Data:  location,  MOG  capacity,  and  specific  use  plans  (off-load,  recovery,  tanker 
bed  down,  etc.) 

d.  Fleet  Availability  Data,  by  day. 

e.  Aircraft  Data:  speed,  fuel  consumption  and  payload. 
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7.  Solution  Method 

NRMO’s  objective  combines  penalties  for  violating  delivery  schedules  or  cargo 
demands  with  penalties  for  actions  that  are  wasteful  or  disrupt  the  smooth  flow  of  operations. 
The  major  penalties  are  associated  with  personnel  and  cargo  that  are  delivered  late  or  not 
delivered  at  all.  Secondary  penalties  are  incurred  for  deadheading  crews  or  for  reassignment  of 
aircraft  from  cargo  to  aerial  refueling  duties  or  vice  versa.  Finally,  a  reward  can  be  earned  for 
resting  aircrews  at  bases  that  are  embarkation  nodes. 

Optimization  is  done  subject  to  the  constraints  shown  in  the  conceptual  formulation. 
The  actual  mathematical  algorithms  used  to  solve  the  problem  will  depend  on  the  choice  of 
solver.  (Melody,  et  al,  1997,  p.  33) 

8.  Results 

Results  from  NRMO  are  applicable  to  analysis  of  airlift  force  structure,  infrastructure 
and  concepts  of  operations.  Because  the  model  uses  available  assets  in  the  most  efficient 
manner,  shortfalls  in  meeting  deployment  requirements  indicate  a  shortage  of  capability  vice  an 
inefficient  scheduling  heuristic  (Melody,  et  al,  1997,  p.  14).  Airlift  force  structure  sensitivity 
analysis  can  be  accomplished  by  varying  input  data.  Additional  airlift  force  structure  questions 
can  also  be  answered  through  minor  changes  to  the  objective  function.  One  example  of  this 
would  be  to  let  the  initial  aircraft  inventory  vary  at  a  cost,  so  NRMO  can  “buy”  the  aircraft  it 
needs  to  complete  the  mission.  Similar  analysis  can  be  done  on  base  infrastructure.  Bases  that 
are  constrained  by  aircraft  parking  or  fuel  available  can  be  quickly  identified.  This  could 
answer  the  question  of  which  bases  would  benefit  most  from  augmentation  of  expeditionary 
airfield  assets.  Insight  into  questions  like  these  can  also  be  gained  using  the  marginal  values  on 
constraints  in  the  GAMS  output. 
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C.  MOBILITY  OPTIMIZATION  MODEL  (MOM) 

1.  Overview 

Of  the  mobility  models  in  NRMO’s  direct  genealogy,  the  only  one  that  included  both  air 
and  sea  components  was  the  Mobility  Optimization  Model  (MOM).  MOM  was  developed  to 
support  the  Mobility  Requirements  Study  (MRS),  that  was  mandated  by  Congress  in  the 
National  Defense  Authorization  Act  for  Fiscal  Year  1991.  The  purpose  of  MRS  was  to  provide 
Congress  with  a  plan  for  force  projection  in  the  21st  Century.  During  the  course  of  MRS,  it 
became  evident  that  no  adequate  models  for  analysis  of  lift  assets  required  to  deploy  forces  were 
available.  While  some  models  could  be  used  to  identify  shortfalls  in  capabilities,  none  could  be 
used  to  identify  how  to  overcome  them.  (Wing,  et  al,  1991,  p.  2) 

MOM  was  designed  to  solve  two  problems.  The  first  (Phase  I  of  the  model),  was  to 
determine  the  minimum  cost  mix  of  lift  assets  needed  to  achieve  on  time  delivery  and 
sustainment  of  forces.  The  second  (Phase  II  of  the  model)  was  to  determine  what  affect  an 
inadequate  mix  of  assets  would  have  on  on-time  delivery  for  a  deployment.  Used  together,  this 
would  allow  planners  to  find  an  optimal  lift  mix  based  on  a  most  likely  scenario  (Phase  I)  and 
then  see  how  it,  or  a  less  optimal  mix,  would  work  for  other  possible  scenarios  (Phase  II) 
(Wing,  et  al,  1991,  p.  3).  MOM  was  modeled  as  a  multi-commodity  network  flow  problem, 
designed  to  be  solved  by  linear  programming.  It  was  implemented  in  GAMS  on  a  personal 
computer  (Wing,  et  al,  1991,  p.  20). 

2.  Organization 

The  formulation  for  MOM  Phase  I  has  five  parts;  the  inventory  problem,  demand 
satisfaction,  air  and  sea  throughput  constraints,  land  and  sea-based  prepositioning  and  the 
objective  function  (Wing,  et  al,  1991,  p.  5).  The  inventory  problem  is  defined  as  what  assets  are 
available  for  each  mission  on  a  daily  basis.  Constraints  on  this  problem  come  from  lift  asset 
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allocation  and  cycle  time,  with  cycle  time  being  the  total  time  a  lift  asset  requires  to  load,  transit 
to  the  theater,  off-load  and  return  to  the  U.S.  To  simplify  this  process,  MOM  aggregated  all 
U.S.  bases  into  a  single  source  node  and  all  terminal  destinations  into  a  single  sink  node  (Wing, 
et  al,  1991,  p  6).  This  gave  reasonable  approximations  for  airlift,  but  required  the  addition  of 
delay  variables  for  sealift,  based  on  the  fact  that  most  men  and  equipment  that  require  sea- 
transportation  must  be  moved  from  home  base  to  their  POE  and  from  their  POD  to  their 
eventual  destination. 

Demand  satisfaction  means  that  the  capacities  of  the  lift  assets  multiplied  by  the  number 
of  lifts,  summed  over  all  lift  assets  during  the  allowed  period  to  move  a  given  unit,  must  equal 
the  unit  requirement  for  that  commodity  (Wing,  et  al,  1991,  p  8).  Demand  satisfaction 
constraints  ensure  that  the  lift  asset’s  capabilities,  multiplied  by  the  number  of  lifts  and  summed 
over  all  assets,  equals  the  unit  requirement  for  each  commodity.  Constraints  are  repeated  for  all 
types  of  cargo.  This  process  was  again  simplified  through  aggregation,  which  was  done  across 
cargo  categories  using  unit  composition  and  lift  asset  capability.  MOM  then  used  a  weighted 
average  capacity  for  each  lift  asset,  given  the  type  of  unit  that  was  to  be  moved.  (Wing,  et  al, 
1991,  p.  8) 

Air  and  sea  throughput  constraints  simply  impose  limits  on  the  number  of  aircraft  and 
ships  that  can  arrive  in  theater,  based  on  theater  capacity.  This  constraint  was  not  imposed  on 
the  Continental  United  States  (CONUS),  as  it  was  felt  the  port  and  airfield  system  in  the  U.S. 
had  a  large  enough  capacity  that  limitations  would  not  be  a  factor.  (Wing,  et  al,  1991,  p.  10) 

Prepositioning  was  handled  by  MOM  as  either  an  input  or  a  decision  variable.  MOM 
accounted  for  the  increased  efficiency  in  the  careful  loading  of  prepositioned  equipment  vice  the 
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more  hasty  loading  performed  during  a  crisis,  and  also  allowed  for  the  return  of  ships  to  regular 
sea-lift  duties  once  their  prepositioned  cargo  had  been  delivered.  (Wing,  et  al,  1991,  p.  10) 

The  Phase  I  objective  function  minimized  the  sum  of  the  cost  of  new  lift  assets  and 
prepositioning  assets.  This  allowed  Phase  I  to  answer  the  question  of  what  was  the  minimum 
cost  and  asset  mix  to  ensure  delivery  and  sustainment  of  forces  throughout  a  given  scenario. 

Phase  II  of  MOM  was  designed  to  determine  the  best  delivery  schedule  that  an 
inadequate  force  of  lift  assets  could  make.  Penalties  were  assessed  for  late  or  undelivered  cargo 
and  the  objective  function  sought  to  minimize  these  penalties. 

3.  Strengths  and  Limitations 

MOM’s  strength  was  not  only  that  it  considered  air  and  sealift,  but  also  the 
prepositioning  of  cargo.  The  inclusion  of  prepositioning  was  especially  useful,  as  this  was  the 
first  model  that  included  use  of  prepositioning  as  a  strategic  lift  option  (Wing,  et  al,  1991,  p. 
20).  Another  strength  was  the  capability  to  model  sustainment  demand.  MOM  kept  a  count  of 
the  number  of  troops  in  theater  and  based  the  demand  requirements  on  that  number.  One  of 
MOM’s  perceived  limitations  was  its  high  level  of  aggregation  (Wing,  et  al,  1991,  p.  21). 
Simplicity  of  the  model  was  traded  for  model  resolution.  In  addition  to  the  aggregation  of  bases 
and  cargo  types,  combat  units  were  deployed  at  the  brigade,  group  and  corps  levels.  In  reality, 
since  MOM  was  designed  to  forecast  the  lift  assets  needed  to  complete  a  major  deployment,  this 
level  of  aggregation  was  appropriate.  A  second  perceived  limitation  is  the  fact  that  MOM  is 
scenario  dependent  (Wing,  et  al,  1991,  p.  270).  Any  change  in  the  scenario  requires  an 
equivalent  change  in  data,  which  makes  the  analysis  of  different  scenarios  somewhat 
cumbersome.  This  “limitation”,  however,  is  certainly  not  unique  to  MOM.  Many  of  the  ideas 
from  MOM  were  incorporated  into  NRMO,  as  will  be  seen  later. 
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D.  MODEL  FOR  INTERTHEATER  DEPLOYMENT  BY  AIR  AND  SEA  (MIDAS) 


1.  Overview 

Another  model  that  considers  both  air  and  sea  components,  and  is  still  in  use,  is  the 
Model  for  Intertheater  Deployment  by  Air  and  Sea  (MIDAS)  (MIDAS  UM,  1997).  MIDAS 
was  developed  by  the  General  Research  Corporation  (GRC)  for  the  Projection  of  Forces 
Division  of  the  Office  of  the  Director  of  Program  Analysis  and  Evaluation,  within  the  Office  of 
the  Secretary  of  Defense  [OD(PA&E)(PF)]  (MIDAS  UM,  1997,  p.  1-3).  MIDAS  is  a  strategic 
deployment  model  that  is  used  to  analyze  airlift,  sealift  and  prepositioning  options  and  can  be 
operated  as  an  integrated  part  of  other  systems  or  as  a  stand  alone  model.  The  current  version, 
MIDAS  2.5,  is  written  in  C++  and  runs  on  Sun  workstations. 

2.  Data  Management 

The  input  data  for  MIDAS  is  similar  to  other  models.  There  are  three  required  input 
files,  as  well  as  additional  files  that  can  be  used  as  appropriate.  As  with  FDE,  MIDAS  files 
generally  use  a  high  level  of  aggregation;  for  example,  the  entire  CONUS  may  be  modeled  as 
having  only  West  Coast,  East  Coast  and  Gulf  ports  (Schank,  et  al,  1991,  p.  61). 

MIDAS  output  can  include  up  to  seven  separate  reports,  covering  ship  and  aircraft  usage 
and  movement,  port  and  airfield  throughput,  load  efficiency,  and  excesses  and  shortfalls  of 
delivery  of  personnel  and  cargo.  Because  these  reports  are  not  available  until  the  completion  of 
the  simulation,  MIDAS  also  writes  a  stream  of  output  while  it  executes.  This  output  allows  the 
user  to  follow  the  simulation  throughout  the  execution.  (MIDAS  UM,  1997,  p.  5-1) 

3.  Methodology 

MIDAS  uses  heuristic  scheduling  algorithms  to  select  modes  of  deployment  for 
personnel  and  cargo,  with  the  goal  of  finding  a  satisfactory,  rather  than  optimal  solution. 
MIDAS  considers  five  deployment  objectives: 


21 


1.  Efficient  use  of  airlift  and  sealift  transportation  resources. 

2.  Timely  delivery  of  forces. 

3.  Arrival  of  forces  in  sequential  order,  as  defined  by  required  delivery  date  (RDD). 

4.  Arrival  of  supplies  in  time  to  sustain  already  deployed  forces. 

5.  Preservation  of  unit  integrity. 

MIDAS  ranks  these  objectives  in  the  order  shown  and  will  work  to  achieve  the  higher 
priority  objectives  at  the  expense  of  the  lower  (MIDAS  UM,  1997,  p.  2-1).  While  the  ordering 
of  these  objectives  is  certainly  reasonable  in  the  sense  of  what  MIDAS  is  used  to  analyze,  from 
a  real  world  viewpoint  it  seems  unlikely  that  any  commander  would  be  willing  to  trade  the 
efficient  use  of  assets  for  the  timely  delivery  of  his  forces. 

MIDAS  uses  an  adaptive  scheduling  approach.  Once  the  deployment  problem  is  solved, 
MIDAS  executes  that  solution.  After  a  period  of  time,  MIDAS  builds  a  new  problem  based  on 
an  updated  status  of  resources,  then  solves  and  executes  the  new  problem.  This  process  is 
repeated  until  the  deployment  is  complete.  (MIDAS  UM,  1997,  p.  2-3) 

Actual  scheduling  of  assets  is  done  by  using  the  RDD’s.  Unlike  other  models,  however, 
MIDAS  does  not  schedule  movements  to  meet  RDD’s,  but  rather  uses  the  RDD’s  to  set 
priorities.  Cargo  is  then  assigned  to  the  mode  of  transportation  that  will  get  it  to  its  destination 
in  the  shortest  amount  of  time.  Mode  assignment  can  be  changed  as  the  scenario  develops,  i.e. 
if  a  faster  type  of  transportation  becomes  available  before  a  load  of  cargo  is  underway,  MIDAS 
will  re-schedule  the  cargo  to  load  on  the  faster  asset.  (MIDAS,  UM,  1997,  p.  2-2) 

4.  Scheduling  Heuristics 

When  ships  are  mobilized,  they  are  assigned  to  a  port  of  embarkation.  As  cargo 
becomes  available  for  loading  at  that  port,  MIDAS  looks  at  empty  ships,  ships  that  are  currently 
loading  and  ships  that  are  scheduled  to  load  in  the  future.  Also  considered  is  the  minimum 
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amount  of  cargo  that  a  ship  must  carry  before  it  will  go  to  a  port  of  debarkation.  A  ship  that 
meets  the  minimum  load  requirement,  can  load  all  the  given  cargo  and  can  deliver  that  cargo  by 
the  earliest  date  is  selected  and  loaded.  Partially  loaded  ships  are  given  preference  over  empty 
ships.  (MIDAS  UM,  1997,  p.  2-5) 

Aircraft  loading  is  accomplished  in  the  same  way,  within  constraints  on  aircraft 
productivity  and  airfield  throughput.  Also  critical  is  the  selection  of  aircraft  routes.  Viable 
routes  are  determined  using  the  range-payload  data  of  the  aircraft,  which  shows  how  far  an 
aircraft  can  fly  based  on  what  payload  it  is  carrying.  MIDAS  ranks  all  possible  routes  using 
flow  rates,  which  are  determined  by  dividing  the  payload  of  the  aircraft  by  the  time  required  to 
complete  the  mission.  The  route  with  the  most  favorable  (lowest)  flow  rate  is  considered  the 
“best”  route.  If,  however,  the  best  route  is  not  available  and  an  alternate  route  that  adds  less 
than  one  day  of  travel  is  available,  the  alternate  route  will  be  chosen.  (MIDAS  UM,  1997,  p.  2- 
5) 

5.  Sustainment  and  Logistics 

Like  MOM,  MIDAS  also  has  the  capability  to  dynamically  generate  sustainment 
demands  for  the  deploying  units.  MIDAS  tracks  the  daily  inventory  of  each  type  of  sustainment 
in  the  supply  pipeline.  As  the  deployment  is  executed,  MIDAS  calculates  sustainment  demand, 
based  on  consumption  rates  and  the  number  of  personnel  in  theater.  If  demand  cannot  be 
satisfied  by  present  inventory,  a  sustainment  requirement  will  be  generated.  These  requirements 
are  normally  delivered  by  ship;  however,  if  current  stocks  are  exhausted  and  demand  cannot  be 
meet  by  sealift,  the  sustainment  requirements  will  be  moved  by  air.  This  is  commonly  referred 
to  as  a  “greedy”  or  “myopic”  heuristic. 
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III.  CHANGES  TO  NAVAL  POSTGRADUATE  SCHOOL  /  RAND  MOBILITY 

OPTIMIZER  (NRMO) 

A.  METHODOLOGY 

NRMO  was  written  strictly  as  an  airlift  model.  In  order  for  it  to  be  useful  to  J-8AVAD 
and  comparable  to  FDE,  however,  it  must  also  handle  sealift.  This  additional  capability 
required  several  augmentations  to  the  existing  NRMO  model.  In  all  cases,  changes  mimicked 
existing  code  in  order  to  minimally  affect  the  initial  model.  The  result  is  the  Naval 
Postgraduate  School  /  RAND  Mobility  Optimizer,  Air  /  Sea  (NRMOAS),  a  version  of  NRMO 
with  the  necessary  additions  to  allow  the  model  to  conduct  both  airlift  and  sealift  operations. 
These  additions  mainly  took  the  form  of  the  additional  sets  required  to  allow  NRMOAS  to 
construct  two  networks:  one  for  aircraft  and  one  for  ships.  The  two  networks  then  required  the 
addition  of  two  sealift-only  constraints,  where  a  single  joint  constraint  would  not  function 
logically.  Finally,  additions  were  made  to  the  output  report  to  accommodate  a  J-8  specific 
requirement.  All  changes  are  detailed  in  the  remainder  of  the  chapter.  The  full  mathematical 
formulation  for  NRMOAS  is  also  included. 

B.  ADDITIONAL  SETS  AND  CONSTRAINTS 

NRMO  has  the  ability  to  represent  an  extensive  and  complicated  air  network.  In  order 
to  allow  NRMOAS  to  set  up  both  an  air  and  sea  network,  it  was  necessary  to  add  sets  to 
distinguish  airfields  from  ports,  aircraft  from  ships  (referred  to  jointly  as  “vehicles”),  and 
airports  of  embarkation  (APOEs)  from  seaports  of  embarkation  (SPOEs).  These  additions  also 
required  the  separation  of  the  variables  used  to  make  initial  allocation  of  vehicles  to 
embarkation  nodes,  thus  ensuring  that  ships  were  not  sent  to  APOEs  and  aircraft  were  not  sent 
to  POEs.  Once  initially  allocated,  ships  travel  only  on  sea  routes  and  aircraft  only  on  air  routes, 
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so  all  other  constraints  can  be  used  by  both  aircraft  and  ships  without  fear  of  redundant  or 
conflicting  use  of  assets. 

Other  changes  that  were  required  dealt  with  port  capacity  and  fuel  consumption 
constraints.  NRMO  uses  the  concept  of  maximum  aircraft  on  ground  (MOG)  to  determine 
airfield  capacity.  MOG  is  defined  as  the  number  of  aircraft  that  an  airfield  can  simultaneously 
service.  It  is  calculated  as  a  function  of  available  aircraft  parking  spaces  multiplied  by  an 
efficiency  factor  that  reflects  available  airfield  services  and  approximates  the  effects  of 
congestion  (queueing).  (Goggins,  Sept,  1995)  NRMO  uses  two  sizes  of  aircraft  to  calculate 
aircraft  parking;  narrow  body  (nb)  and  wide  body  (wb).  All  calculations  use  narrow  body 
aircraft  as  the  base.  Similar  to  MOG,  port  berthing  capacity  is  based  on  ship  length,  so  when 
calculating  port  berthing,  NRMOAS  uses  a  similar  simplified  size  comparison  for  ships.  Small 
ships  (ss)  are  defined  as  800  feet  or  under  in  length,  and  large  ships  (Is)  are  defined  as  over  800 
feet  in  length.  The  equations  which  calculate  ship  berthing  and  aircraft  parking  are  then  simply 
mirrors  of  each  other.  This  leaves  NRMOAS  with  two  similar  sets  of  capacity  constraints, 
MOG  for  aircraft  and  port  capacity  for  ships.  In  the  case  of  an  air  /  sea  aggregate  base,  these 
separate  calculations  allow  the  MOG  constraint  to  account  for  both  aircraft  parking  and  ship 
berthing  without  allowing  either  vehicle  to  use  the  other’s  available  parking. 

C.  CHANGES  TO  OUTPUT  FILE 

One  J-8/WAD  requirement  was  that  the  model  allow  the  user  to  track  the  by-day 
delivery  of  every  unit’s  cargo  and  personnel.  NRMO  did  not  include  this  data  in  its  output  file. 
The  addition  of  a  parameter  to  calculate  this  value,  and  an  additional  loop  in  the  output 
generator  to  print  the  results  easily  accomplished  this  and  also  demonstrated  the  versatility  of 
the  output  generator  in  accommodating  user  needs.  In  addition,  a  set  was  added  to  allow  the 
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user  to  assign  unit  designators  to  line  entries  on  the  TPFDD.  This  makes  the  delivery  reports 
easier  to  use  when  tracking  unit  deliveries.  It  is  important  to  note  that  the  addition  of  actual  unit 
designations  to  deployment  routes  makes  the  data  set  used  classified. 

D.  DATA  COLLECTION 

The  biggest  challenge  to  adding  a  sealift  component  to  NRMO  was  collecting  and 
inputting  the  data  needed  to  allow  NRMO  to  use  ships.  Every  effort  was  made  to  draw  data 
from  FDE’s  database,  so  as  to  give  a  more  valid  comparison.  Since  NRMO’s  aircraft  data  was 
very  complete,  the  main  challenge  lay  in  collecting  and  verifying  the  ship  data.  The  Military 
Sealift  Command  (MSC),  when  fully  mobilized,  has  access  to  1066  ships,  under  both  U.S.  and 
allied  registry.  As  with  aircraft,  the  vast  degree  of  variability  from  ship  to  ship  makes  a  high 
degree  of  aggregation  desirable.  FDE  uses  five  composite  ship  types.  These  ship  types  and 
their  definitions  are  shown  below  and  were  used  in  NRMO  AS. 

Breakbulk  (BB)  -  Ships  in  which  cargo  is  loaded  in  holds 

Fast  Sealift  (FSL)  -  Converted  container  ships.  They  are  the  largest  and  fastest 

ships  in  the  strategic  sealift  force.  Their  mission  is  rapid  transport 
of  Army  unit  equipment 

Lighter  Aboard  Ship  (LASH)  -  Carries  barges  that  are  floated  aboard  and  stacked 
in  slots.  Similar  in  concept  to  stacking  bakery  trays  in  large 
metal  rack. 

Roll  On/  Roll  Off  (RORO)  -  Allow  vehicles  to  “Roll  On”  and  “Roll  Off’ 

Large  Medium  Speed  RORO  (LMSR)  —  Self  Explanatory 
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Values  for  ship  speed,  capacity,  load  and  unload  times  and  fuel  consumption  were  taken 
directly  from  FDE.  Where  information  was  unavailable,  it  was  developed  from  military 
manuals,  phone  calls  and  existing  data  sets.  Additional  data  also  had  to  be  collected  for  the  load 
capacities  of  various  aircraft  and  ships.  A  vehicle’s  load  capacity  varies  from  unit  to  unit.  The 
differences  are  most  noticeable  with  over-sized  and  out-sized  cargo,  which  are  more  limited  by 
cubic  size  than  by  weight.  NRMO’s  load  capacity  tables  dealt  only  with  aircraft.  Similarly, 
FDE’s  capacity  tables,  while  dealing  with  both  aircraft  and  ships,  were  divided  so  that  some 
units  went  solely  by  air  and  others  went  solely  by  sea  (with  the  exception  of  personnel,  which 
always  travel  by  air).  To  allow  NRMOAS  the  ability  to  send  units  by  air  or  by  sea  (see  section 
on  Mode  selection),  load  capacity  tables  were  formed  as  a  composite  of  those  found  both  in 
NRMO  and  FDE.  These  composite  tables  were  not  used  in  every  model  run,  as  will  be 
explained  in  the  chapter  dealing  with  the  model  comparisons. 

E.  MODE  SELECTION 

NRMOAS  operates  with  two  types  of  travel  mode  selection;  user  designated  and  model 
designated.  If  the  user  desires  to  designate  the  mode  of  travel  for  a  a  unit,  he  or  she  simply 
designates  that  unit’s  embarkation  node  as  an  APOE  or  a  POE.  For  example,  if  Dover  Air 
Force  Base  is  designated  as  an  APOE,  any  unit  embarking  from  there  can  only  travel  by  air.  If, 
however,  a  user  wants  NRMOAS  to  decide  the  most  efficient  mode  of  travel  for  a  unit,  the  user 
must  designate  that  unit’s  origin  as  both  an  APOE  and  a  POE.  This  requires  the  creation  of  air  / 
sea  aggregate  bases,  that  can  accommodate  both  aircraft  and  ships.  For  example,  a  unit  could 
depart  from  a  North  Carolina  Air  /  Sea  base  that  aggregates  Pope  Air  Force  Base  and  the  port 
of  Wilmington.  NRMOAS  would  then  determine  whether  the  unit  travels  by  air,  sea,  or  a 
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combination  of  both.  NRMOAS  can  also  be  used  in  a  combined  fashion,  where  the  user 
designates  the  mode  for  some  units  and  the  model  determines  the  mode  for  the  others. 


F.  NRMOAS  FORMULATION 

(Note:  This  formulation  is  adapted  from  the  NRMO  formulation  found  in  the  reference 
Melody,  et  al,  1997.  Much  of  the  formulation  is  reproduced  with  no  change.  Sets  that  have 
been  added  and  constraints  that  were  altered  for  NRMOAS  are  noted  in  bold  type.) 

Indices 

vehicle  type 
base 

cargo  type 
line  id 
route 

time  period 

Note:  In  some  cases,  subscripts  other  than  indices  are  used  to  indicate  subsets. 

Sets 


a 

b 

c 

i 

r 

t 


T  time  periods 

TWi  delivery  time  window  for  line  id  i 

Tu  set  of  time  periods  associated  with  a  ute  rate  constraint  block,  u 

FT  flow  time  periods,  f  =  { 1 , . . . , maximum  mission  time } 

U  utilization  rate  enforcement  blocks 

I  line  id’s 

l fob  subset  of  line  id’s  whose  destination  is  a  FOB 

lapd  -  I/I  fob  subset  of  line  id’s  whose  destination  is  a  APOD 

h.dst  subset  of  line  id’s  that  have  base  b  (FOB  or  APOD)  as  a  destination 

h,tm  subset  of  line  id’s  that  have  base  a  (an  APOD)  as  a  transhippment  point 

Ib.sup  subset  of  line  id’s  whose  destination  is  in  the  theater  belonging  to  super  node  sup 

C  cargo  types  {bulk,  over,  out,  pax } 

CC  cargo  types  {bulk,  over,  out} 

Ca  subset  of  cargo  types  that  can  be  carried  by  vehicle  type  a 

A  set  of  vehicle  types 

A-acft  subset  of  vehicle  types  that  are  aircraft 

Ac  subset  of  vehicle  types  that  can  carry  cargo  type  c 

Amix  subset  of  vehicle  types  that  can  carry  pax  and  at  least  one  other  cargo 

type  {bulk,  over,  out} 

Apax  subset  of  vehicle  types  that  can  carry  passengers 

Aship  subset  of  vehicle  types  that  are  ships 
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A,kr  subset  of  tanker  aircraft  types 

Arp  subset  of  vehicle  types  that  can  be  refueled  by  a  tanker 

AChP  subset  of  vehicles  that  can  be  “chopped” 

B  set  of  all  “bases”  (APOE, APOD, FOB, super, enroute,waypoint,beddown, 

aerial  refueling  points  or  ports) 

Bsup  subset  of  bases  that  are  supemodes 

Baf  subset  of  bases  that  are  airfields 

Bport  subset  of  bases  that  are  ports 

Be  subset  of  bases  that  are  embarkation  nodes 

Bapoe  subset  of  embarkation  nodes  that  are  air  embarkation  nodes 

Bspoe  subset  of  embarkation  nodes  that  are  sea  embarkation  nodes 

Barp  subset  of  bases  that  are  AR  points 

Btkr  subset  of  bases  that  are  beddown  bases  for  tankers 

BSnc  set  of  super  nodes  that  have  at  least  one  recovery  base 

Bway  set  of  bases  that  are  enroute  navigational  waypoints 

BSb.dwn  set  of  super  nodes  that  have  b  as  a  shuttle  beddown  node 

BSb.sup  set  of  FOB’S  that  call  b  their  super  node  plus  the  super  node  itself 

BAb.tkr  subset  of  Barp  that  are  served  by  b  e  B,kr 

BTb.arp  subset  of  B,kr  that  serve  b  e  Bsup 

Bcrw  crew  stage  bases 


Routes 


R  set  of  all  routes 

RD  subset  of  routes  that  are  delivery  routes 

RB  subset  of  routes  that  are  backchannel  routes 

RBrec  subset  of  backchannel  routes  that  include  a  recovery  base 

RDb  delivery  routes  that  use  base  b  (terminal  node  is  a  super,  not  FOB 

or  APOD) 

RDia,dir  subset  of  routes  that  can  be  traveled  by  a  vehicle  of  type  a  and  carry  i  for  direct 

delivery 

RBab  subset  of  backchannel  routes  that  use  b  and  can  be  traveled  by  a  vehicle  of  type  a 

RDb,div  set  of  delivery  routes  that  have  b  as  a  divert  base 

RBb.div  same  for  backchannel  routes 

Rb.ori  routes  whose  origin  is  base  b 

Rbfdst  routes  whose  destination  is  base  b 


Data 

Mission  time  data 

rtrvar  total  travel  time  for  vehicle  a  to  travel  on  route  r  (periods) 

trvar  rounded  rtrvar  (integer  periods) 

retrvabr  travel  time  for  vehicle  a  to  reach  base  b  when  traveling  route  r  (periods) 

etn>abr  rounded  retrvabr  (integer  periods) 
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maxtrva 

msntimearf 


flttimearf 


gtimeabr 


qtimeabr 


ctrvabr 

CttrVab 

dhtrvb’b 

rttrvab 


ttrvab 

tkrtimeabb' 

tkrrateabb' 

shutrateai 

gtrvi 

shuttimeia 


maximum  travel  time  along  any  route  for  vehicle  a  (integer  periods) 
time  flown /periods  into  a  mission  (hours),  where/is  a  time  period  used  to 
calculate  flight  hours 

•  hrsper  if  rtrvar  > /(mission  continues  throughout  its/th  period) 

•  0  if  rtrvar  ^ f-1  (mission  terminates  before  its/th  period) 

•  hrsper  ■  ( rtrvar  -  (f-1))  if/-l  <  rtrvar  <  /(mission  terminates  during  its/th 
period) 

same  as  msntimearf,  but  only  includes  actual  travel  time,  thus, 
flttimearf  <  msntimearf,  since  all  missions  have  some  ground  or 
port  delay  time 

ground  or  port  delay  time  for  vehicle  a  at  base  b  when  traveling  route 
r  (hrs) 

offload  time  for  vehicle  a  at  base  b  when  traveling  route  r  when  recovery 
used  (hrs) 

travel  time  to  b,  plus  crew  rest,  for  a  along  r  (integer  periods) 
ttrvab  plus  crew  rest  (integer  periods) 

travel  time  for  deadheading  crew  from  b  'to  b  (integer  periods) 
tanker  a  reposition  time  (approx  2  days)  from  embarkation  or  beddown 
base  b  to  cloud 

rounded  rttrvabr  (integer  periods) 

in-flight  time  for  tanker  a  flying  from  b  to  b  'and  back  (UTE)  (hrs) 
maximum  number  of  in-theater  shutles  per  aircraft  per  period 
maximum  number  of  in-theater  shuttles  per  aircraft  per  period 
in-theater  ground  travel  time  for  i  (periods) 
shuttle  travel  time  (for  UTE)  (hrs) 


Vehicle  data 


newvat 

cumat 

crewrata 

purecapiaC 


maxpaxa 

paxfraca 

rangefaciar 

restrewa 

usepena 

dhpena 

tkrpropabb’ 

dpcta 

uratea 

initchopab 


number  of  new  vehicles  of  type  a  available  in  period  t 
=  newva,' 

ratio  of  available  crews  to  vehicle  a 

number  of  stons  of  unit  i’s  cargo  of  type  c  that  can  be  loaded  on 
vehicle  type  a 

maximum  number  of  pax  that  can  be  loaded  on  vehicle  type  a 
fraction  of  a  vehicle’s  capacity  that  can  be  loaded  with  pax 
fraction  of  vehicle  available  for  loading  when  flying  route  r  for  line  id  i 
unit  reward  for  resting  vehicle  at  base  b  eBe 
(maxic  { purecapiac }  •  latepent  •  0.01) 
usage  penalty  for  theater  aircraft  and  tanker  reassignments 
penalty  for  deadheading  crews 

proprotion  of  a  full  tanker  consumed  by  aircraft  a  refueling  at  AR  b  on  r 
(KC10  equiv) 

fraction  of  AR  attempts  by  aircraft  a  (the  one  getting  the  fuel)  that  fail 
number  of  hours  per  day  that  vehicle  a  can  operate 
initial  vehicles  chopped  to  theater 
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Movement  requirements  data 


rddj 

demjC 

lateperii 

maxlatei 

nogopetij 


required  delivery  date 

stons  of  demand  for  line  id  i  of  type  c 

late  delivery  penalty  for  i  per  day  per  ston 

maximum  number  of  time  periods  late  delivery  for  line  id  i  can  arrive 
non-delivery  penalty  per  ston  ( >  lateperii  ■  maxlatei ) 


Other  data  and  notational  conventions 


hrsper 

number  of  hours  per  period 

acpkgab 

unit  MOG  consumption  of  vehicle  a  at  base  b 

mogeffb 

MOG  efficiency  at  b 

mogb 

base  capacity;  service  spot  hours  per  period  at  b 

I(-) 

1  if  argument  is  true;  0  otherwise 

(x)+ 

=  max{0,x} 

S 

complement  of  a  generic  set  S 

In  general,  constraints  and  variables  indexed  by  t  are  assumed  to  exist  only  for  the  appropriate 
combinations  of  t  with  those  other  indices. 


DECISION  VARIABLES  (all  non-negative) 
Vehicle  mission  variables 


XDiarf 
XT iart 


XDRiart 

XTRian 


XSin 


TKRAabb’t 


#  of  vehicles  a  direct  delivering  i  on  route  r  departing  at  time  t 

#  of  vehicles  a  delivering  a  transshipment  load  of  i  on  route  r  departing 
at  time  t 

#  of  vehicles  a  direct  delivering  i  on  quick  route  r  departing  at  time  t 

#  of  vehicles  a  delivering  a  transshipment  load  of  i  on  quick  turn  route  r 
departing  at  time  t 

#  of  (Round  trip)  shuttle  missions  by  vehicle  a  delivering  i  in  t 

#  of  vehicle  a  recovering  on  route  r  departing  at  t 

#  of  tanker  sorties  of  type  a  flown  from  b  €  Btkr  to  b  ’  e  Barp  in  t 


Vehicles  inventory  variables 


RONAPOEabt 

RONPOEab, 

RONTabl 

RONRabt 

IRONRab 

IRONRab 

THCHOPab, 

THCHOPRab, 


#  of  aircraft  a  remaining  over  night  at  b  eBe\nt 

#  of  ships  a  remaining  over  night  at  b  e  Be  in  t 

#  of  vehicles  a  “RONing”  without  recovery  in  t 

#  of  vehicles  a  “RONing”  with  recovery  in  t 

#  of  vehicles  a  initially  assigned  to  b  (non-recovery) 

#  of  vehicles  a  initially  assigned  to  b  (recovery) 

#  of  vehicles  a  assigned  to  super  b's  shuttle  fleet  from 
non-recovery  routes  in  t 

#  of  vehicles  a  assigned  to  super  b’s  shuttle  fleet  from 
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recovery  routes  in  t 

TKRBabt  #  of  tankers  a  whose  beddown  base  is  b  e  B,kr  in  t 


Vehicles  changing  roles 

ALLOCACFTabt  #  of  new  aircraft  allocated  to  b  e  Bapoe  in  t 

ALLOC S HIP abt  #  of  new  ships  allocated  to  b  e  Bpoe  in  t 

TKRECabt  #  of  tankers  a  leaving  b  e  Be  in  t  for  service  as  a 

re-fueler  (for  cloud) 

TKRCEabt  #  of  tankers  a  leaving  tanker  fleet  (cloud)  in  t  for  b  e  Be 

for  cargo  hauling 

TKRBCabt  #  of  tankers  a  assigned  a  super  b' s  shuttle  fleet  from 

non-recovery  routes 

TKRCBabt  #  of  tankers  a  being  reassigned  (from  cloud)  in  t  to  b  e  Be 

for  refueling 

Cargo 

DTONSiact 

TTONSiact 

STONSiac 

GTONSict 

NOGOic 

Crews 

SCREWS  abt  #  of  crews  available  (rested)  for  a  at  b  e  Bcrw  at  the  beginning 

of  time  t 

DH CREWS ab’bt  #  of  deadheadiing  crews  for  a  leaving  b  ’  at  time  t  for 

reassignment  to  b 


stons  of  i’s  cargo  of  type  c  direct  delivered  by  a  that  will  arrive  in  t 

stons  of  i’s  cargo  of  type  c  for  transshipment  by  a  arriving  at 

(the  transshipment  node)  in  t 

stons  of  i’s  cargo  of  type  c  shuttled  by  a  in  t 

stons  of  i’s  cargo  of  type  c  ground  that  will  arrive  at  the  FOB  in  t 

stons  of  i’s  cargo  of  type  c  not  delivered 
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OBJ:  Objective  Function 


ZEE  E  latepeni  •  (t-rddjY  DTONSiact 

iel  aeA  ceCa  teTWj 

+  Z  Z  Z  Z  '  (l-rddif  •  STONSiact 

i&I  at  A  c^Ca  t^TWi 

+  E  EE  nogoperi;  ■  (t  -  rdd )  Y  ■  GTONSjct 
iel  fob  c<=C  teTWj 

+  E  E  nogopeni  •  NOGOic 
iel  ceC 

+  E  EE  usepena  •  [THCOPabt  +  THCHOPRabt ] 
a^^chp  beB^p  teT 

+  E  EE  usepena  •  TKRECabt  +  E  EE  usepena  ■  TKRBCabt 
aeA,kr  beBe  teT  a.eAlkr  beBtkr  teT 

-  E  E  E  restrew a  -  (RONAPOEabt  +  RONPOEabt)  + 
aeA  beBe  teT 

E  Z  E  •  DHCREWabb't 

°eAtkr  bb  eBcrw  teT 

Minimize  the  sum  of:  (1)  late  penalty  *  number  of  days  late  *  late  cargo  delivered  directly  to  the 
line  id’s  destination,  (2)  late  penalty  *  number  of  days  late  *  late  cargo  shuttled  (from  the 
transshipment  base)  to  the  line  id’s  destination,  (3)  late  penalty  *  number  of  days  late  *  late  cargo 
delivered  by  ground  from  the  transshipment  base,  (4)  nondelivery  penalty  *  undelivered  cargo, 
(5)  usage  penalty  *  chopped  vehicles  or  reassigned  tankers,  (6)  a  small  reward  (negative  penalty) 
*  vehicles  remaining  overnight  at  an  embarkation  node  (often  CONUS,  and  thereby  near  home 
station),  and  (7)  crew  deadhead  penalty  *  deadheading  crews. 


ACBALAPOE:  Aircraft  Balance  at  Air  Embarkation  Nodes  (Change  from  NRMO) 

I  £  +  £  £  xdm 

ielf0b  reRDbr\RDialni  iel  reRDbr^RDmdir 

+  £  £  +  £  £  xdr,.„ 

ielfoh  reRDbnRDiatni  iel  reRDbnRDiadir 

+  I(a  e  Alkr)  ■  [ TKRECaht  ]  +  RONAPOEabt  =  RONAPOEab  tA  + 

reRBab 

+  ALLOCACFT ^  +  I(a  e  Atkr)  ■  [TKRCE^] 


Vue  Aacft,  b  e  Bapoe>  t  e  T 
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Aircraft  Balance  at  APOEs:  For  each  aircraft  type,  APOE,  and  time  period  (day);  departing 
transshipment  missions  +  departing  direct  delivery  missions  +  assignments  to  tanker  duty  (if 
aircraft  is  a  tanker)  +  overnight  resting  aircraft  =  resting  aircraft  from  yesterday  +  arriving 
backchannel  missions  +  newly  assigned  aircraft  +  reassignments  from  tanker  duty  (if  aircraft  is  a 
tanker).  Note  that  direct  delivery  missions  and  transshipment  missions  can  be  selected  to  recover 
away  from  the  APOD  (XDR,  XTR)  or  recover  at  the  APOD  (XD,  XT)  missions.  This  is  true 
throughout  the  formulation,  except  as  noted. 


SHBALPOE:  Ship  Balance  at  Sea  Embarkation  Nodes  (Change  from  NRMO) 


z 

Z  XT»» 

+  Z  Z  +  RONPOEa, 

reRDbr\RDiam 

iel  reRDbnRDiadir 

= 

RONPOEahtA  + 

Z  +  allocship^ 

- 

r^RBab 

v  a  e  Aship,  b  e  Bpoe,  t  e  T 

Ship  Balance  at  SPOEs:  Same  for  ACBALAPOE,  but  balances  numbers  of  ships  at  POE’s  only. 
Note  that  ships  will  not  be  assigned  to  tanker  duty. 


VBALSUP:  Vehicle  Balance  at  SUPER  Debarkation  Nodes 


Z_  Y-  +  RONT*  +  mcH0P°»  = 

reRBabr\RBrcc 

Z  X  + 1  X  + 

iel/0b  reRDbr\RDialrn  ief  reRDbnRDia,dir 

*ONTm  +  THCHOPabtA  +  I(t  =  l)  ■  IRONab 


Va  e  A,  be  BSS[ip,t  e  T 

Vehicle  Balance  At  Super  Nodes:  A  “super”  node  is  a  surrogate  for  all  bases  in  the  theater. 
Flow  balance  is  done  with  supers,  but  MOG  is  constrained  at  the  actual  theater  POD’s  and 
FOB’S.  Additionally,  this  constraint  only  addresses  missions  that  recover  at  the  POD.  Other 
missions  are  constrained  in  VBALREC.  For  each  vehicle  type,  “super”,  and  time  period;  the 
departing  backchannel  missions  +  ovemightr  resting  vehicles  +  total  vehicles  chopped  to  the 
theater  =  arriving  transshipment  missions  +  arriving  direct  delivery  missions  (for  those  line  id’s 
whose  destination  is  an  POD)  +  last  nights  resting  vehicles  +  yesterday’s  total  of  chopped 
vehicles  +  the  initial  “chops”  to  theater  (if  it  the  first  time  period). 
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VBALREC:  Vehicle  Balance  at  SUPER  Debarkation  Nodes 


Z  Y„  +  RONRahl  +  THCHOPR A  = 

reRBabnRBrec 

Z  Z  X7K.  +  Z  Z  + 

•  €/ /ot>  r ^ Cl R^ia, trn  r  € 

RONRaM  +  THCHOPRahtA  +  7(/  =  U  •  IRONR^ 

V  a  e  A,  be  BSrec,  t  e  T 

Vehicle  balance  at  super’s  using  recovery  routes:  Same  as  VBALSUP,  but  balance  flow  for 
missions  not  recovering  at  the  POD 

INITRON:  allocate  initial  chops  to  recovery  or  not 

IRONTab  +  lRONRab  =  initchopab  \/  a  e  Achp,  b  e  Bsup 

Initial  RONS  in  theater:  For  period  1  and  all  vehicles  and  supers;  the  sum  of  RONS  at  POD 
recoveries  +  RONS  at  non-POD  recoveries  =  initial  aircraft  chopped  to  theater. 

ACFTALLOC:  allocate  newly  available  aircraft  (Change  from  NRMO) 

X  ALLOCACFTabt  =  newvat  V  a  e  Aacp,  t  e  T 

beBapoe 

Aircraft  allocation:  For  each  aircraft  type  and  time  period;  the  sum  of  all  new  allocations  to 
APOE’s  =  the  amount  newly  available. 

SHIPALLOC:  allocate  newly  available  ships  (Change  from  NRMO) 

X  ALLOCSHIPabt  =  newvat  V  a  e  Aship,  t  e  T 

beB  p0e 

Ship  Allocation:  Same  as  ACFTALLOC,  but  for  ships  only. 
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SHUTLBND:  don’t  send  more  tankers  than  available 


I 


b.sup  ^  I  fob 


XSiat 

shutrateia 


<  [THCHOPabt  +  THCHOPRabt] 

Va  €  Aacft>  B  £  Bsup,  t  s  T 


Shuttle  Bound:  For  each  vehicle  type,  “super”  pod,  and  time  period;  the  number  of  round  trip 
shuttle  missions  divided  by  the  daily  number  of  round  trip  missions  per  aircraft  <  total  chopped 
vehicles  in  the  theater. 


TKRBND:  don’t  use  more  tankers  than  available 


I 

A'eBAb.tkr 


TKRAgbb’t 

tkrrateabb> 


<  TKRBabt 


Va  e  Atkr’,  b  e  Btkr>  t  s  T 


Tanker  Bound:  For  all  tankers,  tanker  beddown  bases,  and  time  periods;  the  number  of  AR 
sorties  flown  to  all  tracks  divided  by  the  daily  sortie  rate  <  tankers  assigned  to  the  beddown  base. 


CLOUDBAL:  flow  balance;  leaving  and  entering  tanker  fleet 


2  TKREC^  +  ZTKRBC^,,  = 

Bapoc  &tkr 

Y,TKRCE^,  +  ZTKRCB^,  Va  £  A,w  ,  s  T 


Tanker  Cloud  Balance:  The  “tanker  cloud”  is  an  expression  for  the  act  of  assigning  or  de¬ 
assigning  multi-role  aircraft  as  dedicated  tankers.  The  “cloud”  serves  as  a  control  point  that 
reduces  the  number  of  required  assignment  and  de-assignment  variables.  For  all  tanker  aircraft 
types  and  time  periods;  newly  assigned  tankers  from  all  APOE’s  (adjusted  for  travel  time)  + 
newly  de-assigned  tankers  from  all  tanker  beddown  bases  (adjusted  for  travel  time)  =  tankers 
returning  to  all  APOEs  +  tankers  deploying  to  all  beddown  bases.  Note  that  de-assigning  a 
tanker  from  a  beddown  base  does  not  force  it  back  to  an  APOE,  it  could  be  re-assigned  to 
another  beddown  base. 
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TKRINVT:  tanker  inventory  at  tanker  beddowns 

TKRBCabt  +  TKRB, *  =  TKRCBab,  +  TKRBahM  Va  e  Atkr,  b  €  5,ir,  l  €  T 

Tanker  Inventory:  For  all  tankers  aircraft  types,  tanker  beddown  bases,  and  time  periods;  newly 
de-assigned  tankers  +  total  tankers  assigned  =  newly  assigned  tankers  +  total  tankers  assigned 
from  last  period. 


ARMOG:  aerial  refueling  capacity  constraint 

I  E  Z  tkreqvs^  •  XDi  a  r  ,_etn,abr 

iel  aeArJ1  reRDbnRDiadir 

+  I  I  E  tkre(lVSabr  ■  XTi  a  r  J_em,ahr 

iel  aeArfi'  re RDb ^RDia,im 

+  X  X  Z  tkre<lVSabr  ■  XDR,c,,-"nabr 

ie!  acArf  reRDbr>RDiadir 

+  Z  Z  Z  tkreClVSabr  •  XTRi  a  rJ_etn.abr 

iel  aeAy  r<=RDbnRDialm 

Z  Z  tkreClVSabr  •  Ya.r.,.e,r.ab, 

aeArfl  reRBab 

-  Z  Z  tkrProPabb  •  TKRA^h,  Vb  e  Barp,t  e  T 

b'€BTbarp  aeA,kr 


Air  Refueling  MOG:  Despite  the  apparent  contradiction  in  terms,  this  constraint  is  the  air 
refueling  analog  to  airfield  MOG.  It  constrains  the  capacity  of  an  AR  track.  For  all  air  refueling 
points  and  time  periods;  the  fuel  required  by  direct  delivery,  transshipment,  and  backchannel 
missions  hitting  the  track  in  this  time  period  <  the  amount  of  fuel  available  by  tanker  sorties 
flown  to  the  track. 
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UTE:  utilization  rate 


Z  Z  Z  Z  *  XD,M.m) 

teTu  iel  reRD,aJ„  fzFT 

+  Z  Z  Z  Z  flttimearf  ■  ,, 

f0b  reRDiatrn  f  eFT 

+  Z  Z  Z  Z  flttimearf  ■  XDRiart_(fA) 

teTu  iel  reRDiadir  f  eFT 

+  £  Z  I  I  ^‘"“W  •  X7K, 

/€7«  fob  rG^^ia,tm 

+  Z  Z  shuttime,,  •  XSifl,  +  X  Z  Z 

,€/ fob  teTu  teTu  reRBb  feFT 

+  l(a  e  Atkc)  ■[  Y,  Z  Z  tkrtimeabb-  *  TKRAabb,  + 

bsBltr  b'eBarp  teTu 

Z  Z  hrsPer  •  mrvofc  •  TKREC*  + 

V*  /€ri( 

X  X  *"/>«■  •  •  TKRBCab,  ] 

b^Btkr  *€TU 

<  X  cumacat  •  wratefl  V  a  €  Aacf),  u  e  U 

teTu 


Utilization  Rate:  Sums  all  varieties  of  travel  time,  so  the  left-hand  side  of  this  constraint 
accumulates  travel  time  only  of  missions  operating  during  blocks  of  UTE  rate  enforcement 
(typically  10-20  day  blocks).  For  each  vehicle  type  and  UTE  rate  block;  the  travel  time  of  all 
direct,  transshipment,  shuttle,  and  backchannel  missions  (as  well  as  deployed  and  deploying 
tankers,  if  appropriate)  <  total  vehicles  available  *  maximum  hours  per  day  of  average  vehicle 
utilization.  The/index  corresponds  to  the  number  of  days  into  a  mission,  so  when/=  1,  a 
typical  term  is  the  flight  time  of  a  mission’s  first  day  *  the  number  of  missions  (of  that  type) 
launched  that  day.  Similarly,  when/=  2,  a  typical  term  corresponds  to  the  flight  time  of  a 
mission  s  second  day  *  the  number  of  missions  (of  that  type)  launched  on  the  previous  day. 
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VCONSUME:  max  vehicle  usage  to  lessen  rounding  effects 


ZEE  msntimearf  ■  XDiarl_(fA) 

iel  reRDiadir  feFT 


+ 

I 

z 

Z 

msntimearf 

•  XT,*. 

ieIfob 

r*RDw.,m 

feFT 

+ 

I 

Z 

z 

msntimearf  • 

xdrl 

iel 

reRDjadjr 

feFT 

+ 

z 

z 

z 

msntimearf 

■  XTRi 

ieI/ob 

r^RD,a.,m 

feFT 

y  hrsper 
ie,/ob  shutrateai 


+  E  E  msntimearf  •  Yasj-W 

reRB  feFT 


+  I(a  €  Alkr)  •[  X  E 


hrsper 


„,B,kr  b'eBarp  tkrrateabh. 


TKRAahb,  + 


I  rttrvab  •  hrsper  •  TKRECabt  + 

-  Rapoe 

E  rttrv“h  ■  hrsper  ■  TKRBCabt  ] 

beBtkr 

+  2 hrsper  ■  RONAPOEab,  +  £ hrsper  ■  RONPOEi 

b€Bap0e  beBpoe 


beB^ 


<  hrsper  •  cumaca 


V  a  €  A  t  e  r 


Vehicles  Consumed:  Structurally  similar  to  UTE,  this  constraint  reduces  the  effect  of  time 
discretization.  It  supplements  the  flow  balance  constraints,  which  may  deal  with  short  missions 
whose  rounded  duration  is  0  periods.  For  all  vehicle  types  and  time  periods;  mission  time  of  all 
direct,  transshipment,  shuttle,  and  backchannel  missions  (as  well  as  deployed  and  deploying 
tankers,  if  appropriate)  +  resting  aircraft  <  total  vehicle  hours  available. 
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DCAPACITY:  direct  delivery  capacity 


y  DTONS^  h 

ceCar>CC  P^eCUp iac 

<  Yj  mnSefaCiar 

reRD*,dir 


paxfraca  ■  DTONSia 


paxjt 


I(a 

maxpaxa 


V/  e  I,  a  e  A,  t  e 


T 


Direct  Delivery  Mission  Capacity:  For  each  line  id,  vehicle  type,  and  time  period;  the  number  of 
tons  delivered  (summed  over  cargo  classes)  divided  by  the  vehicle  capacity  by  cargo  type  and 
unit  +  the  passengers  delivered  divided  by  the  passenger  capacity  <  the  number  of  missions 
launched  in  support  of  i  by  vehicle  of  type  a  along  any  route,  launched  long  enough  ago  so  as  to 
be  arriving  at  time  t.  paxfrac  specifies  the  portion  of  the  vehicle  filled  if  fully  loaded  with 
passengers.  Parameter  rangefac  is  frequently  1,  but  is  reduced  if  the  critical  leg  is  long  enough  to 
exceed  the  vehicle’s  range/payload  performance. 


TCAPACITY:  transshipment  delivery  capacity 

y  TTONS^  +  Paxfrac«  ■Tr0NS<,a,pq»  .  I(a  6 
cec^cc  purecapiac  maxpaxa 

<  Y  ranSefaCiar  ■  Wi*. W-mw  +  XDTRi  a  mr  ] 

reRDia.m 


Apax) 

V  i  €  Ifob,  a  e  A,  t  e 


T 


Transshipment  Mission  Capacity:  Same  as  DCAPACITY,  but  applies  to  missions  flown  in 
support  of  cargo  and  pax  deliveries  to  transshipment  POD’s  (for  subsequent  transshipment). 


S  CAPACITY:  shuttle  delivery  capacity 

y  STONSjact  paxfrac a  •  STONSia  ,paxyt 

2-t  '  *  HO-  ^  Aryax) 

c€CanCC  Purecapiac  maxpaxa  F 

<  srangeia  •  XSiat  V  i  e  I  fob,  a  <=  A,  t  e  T 

Shuttle  Mission  Capacity:  Same  as  DCAPACITY  and  TCAPACITY,  but  applies  to  intra-theater 
missions  moving  cargo  from  transshipment  POD’s  to  FOB’s. 
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DPAXCAP:  direct  delivery  of  pax 


DTONSiapaxt  < 
X  max  pax a  • 

reRDiadir 


\XD. 


i.a.r.t-trv., 


+  XDR 


V  i  e  I,  a  e  Amix,  t  e  T 


Direct  Delivery  Mission  Pax  Capacity:  For  each  line  id,  vehicle  type,  and  time  period;  the 
number  of  pax  moved  must  not  exceed  the  maximum  pax  per  mission  *  number  of  missions 
executed.  It  supplements  DCAPACITY,  which  would  (by  itself)  allow  for  aircraft  to  be  fully 
loaded  with  pax,  despite  available  seating  configurations.  NOTE:  DTONS,  TTONS,  and  STONS 
represent  number,  not  tons  of  pax. 


TPAXCAP:  delivery  of  pax  for  transshipment 
TTONS, < 

X  maxpaxa  •  [xTiam  +  XTR  ]  VieIfoh,ae  Amix ,  t  e 


T 


Transshipment  Mission  PAX  Capacity:  Same  as  DPAXCAP,  but  applies  to  transhipment 
missions. 


SPAXCAP:  delivery  of  pax  by  shuttles 

STONS ja> Pax,t  ^  maxpaxa  •  XSait  V i e  Ifob,ae  Amix,teT 

Shuttle  Mission  PAX  Capacity:  Same  as  DPAXCAP  and  TPAXCAP,  but  applies  to  intra-theater 
shuttle  mission. 


MEETDEM:  meet  demand  for  each  line  id 


E  Z  DTONS iact  +  NOGOic 

aeAc  teT 


+  /  (ieIfob  )■ 


I  I 

aeAc  teT 


STONS iact  +  X  GTONSict 

teT 


=  demic 


VieI,ceC 


Meet  Demand:  For  each  line  id  and  cargo  class;  direct  delivery  tons  (and  pax)  moved  by  all 
vehicles  over  the  available  time  window  +  tons  moved  by  shuttle  missions  (if  destination  is  a 
FOB)  +  tons  moved  by  ground  (if  destination  is  a  FOB)  +  cargo  NOT  moved  =  demand  by  unit 
and  cargo  class. 
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TRANSTONS:  flow  balance  for  transshipped  stons 

Z  rrom =  £  stons, +  GTONSUJn,„,  v  i  <=  i,c  <=  c,t  <=  t 

aeAc  aeAc 


Transshipment  Tons:  For  each  line  id,  cargo  class  and  time  period:  transshipment  tons  moved  by 
strategic  lift  =  tons  moved  to  FOB  by  shuttle  or  ground  transport. 


INITCREWS:  initialize  crew  placement 

Z  SCREWS  ^  +  crewrata  •  TKRB ^  =  crewrata  •  newacal  V  a,  t  =  1 


Initialize  Crews:  For  all  vehicles  and  time  period  1;  strategic  lift  crews  available  at  all  crew 
stage  bases  +  crew  contingent  for  all  pre-deployed  tankers  =  number  of  crews  available. 


SCREWBAL:  strategic  crew  balance  of  flow 
SCREWS  abt+l  =  SCREWS ^ 


+ 

I 

Z_ 

\XDi  a  r  t.ctrVabr  +  XDRLatrj-cirvahr  . 

1 

/€/  reRDiadir  n  Rb.ori 

+ 

z 

z_ 

+  ^^^i,a,r,tctnabr 

] 

ieI /ob  reRDiaJmn  Rb,ori 

+ 

z. 

Y 

a,r  ,t-ctrvabr 

~  Z  Z  _  lXDi,a  r,,.e,rvabr  +  XDRi,a,r,t-etrVllbr  ] 

r<=RBn  /?*>< 

,ri 

reRDj Rb.dst 

— 

z 

Z 

\^i,a,r,t-etrvabr  +  ^^i,a,r^etrvabr  ] 

fob  r&RDia.tn Rb.dst 

- 

W  +  I  (b  e  Bapoe)  •  crewrata  ■ 

frKRCE^^-TKREC*,,] 

reRBn  Rb.ds t 


+  I(b  e  Bsup )  ■  crewrata  ■  \fHCHOPaXtA  -  THCHOPabl  +  I(t  =  l)  •  IRONT^] 

+  I(b  e  BSrec)  •  crewmta  ■  \fHCHOPRabtA  -  THCHOPRabt  +  I(t  =  l)  ■  IRONRah ] 

+  I(b  e  Be,t  *  1,  newacat  >  0)  ■  crewrata  -  (ALLOCACFTabJ  +  ALLOCSHIPabt ) 

+  Z  DHCREWa  b,MrVb,b  -  X  DHCREWm,,  V azAaqft,b  e  Bcm.  t  e  T 

Strategic  Crew  Balance:  For  all  vehicles,  crew  stage  bases,  and  time  periods;  the  number  of 
crews  available  tomorrow  =  number  of  crews  available  today  +  crews  coming  out  of  crew  rest 
from  previous  direct,  transshipment,  and  backchannel  missions  -  crews  required  for  departing 
direct,  transshipment,  and  backchannel  missions  +  the  net  crews  made  available  from  tanker 
deployments  and  returns  (if  APOE  and  tanker  aircraft)  +  the  net  crews  made  available  from 
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“chopped”  and  “unchopped”  vehicles  (if  “super”  POD)  +  new  crew  allocations  +  arriving 
deadhead  crews  from  other  bases  -  deadhead  crews  departing  for  other  bases. 


MOG:  base  capacity 


Z  Z  Z  Stimeabr  ■  acpkgab  ■  [xDi  ,a,r  j-etrv^  +  XDRi  a  r  t  etn,  b  j 

iel  aeA  reRDbnRDladlr 

+  Z  Z  Z  8timeabr  •  acpkgah  ■  XDia  rMn.ar 

ieh.dst  oeA  reRDtadlf 

+  z  Z  Z  qtimeakr  •  acpkgob  •  XDRia  r  MrVm 

iefbdsr  aeA  reRDiadir 

+  Z  Z  Z  Stimeabr  •  acpkgah  •  [xTi  a  r  betn.  br  +  XTRi  a  r  l_e!n,abr  ] 

iel  aeA  reRDbnRDtalm 

+  Z  Z  Z  8timeabr  •  acpkg  ab  •  XTiM  rMn.or 

<*eA  reRDiatn 

+  Z  Z  Z  <itimeabr  •  acpkgab  ■XTRi  a  r  utn,ar 

ie*b.lm  aeA  r*RD,a.tm 

+  Z  Z  sStimeah  ■  aCpkgah  ■  XSiat 

b.dst  ^  fob  OZA 

+  2  S  hrsPer  '  acPkSob  ■  [ THCHOP, +  THCHOPR,,,] 

b'eBsupnBSbdH.n  aeA 

+  Z  Z  Stimeabr  •  acpkgab  •  Ya  r  ,_em^ 

aeA  reRB ^ 


+  I(beBtkr)  ■ 


hrsper  ■  acpkg ah  •  TKRB 


azAtkr 
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aeAr/1 

reRDbdivnRDic 
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■  gtimeabr 

■  acpkgab 

XDRia  rt.etn.atr 
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a^Arfl 
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dpcta 

•  gtime^ 
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aeAy 

reRDb  dWnRDiatrn 
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dpcta 

•  gtimeabr 

■  acpkgah 

•  XTRiaruetrx^ 

iel 

aeAr/1 

reRDb,divnRDia.tm 

+ 

z 

z 

dpcta  ■ 

gtimeabr 

•  acpkgab 

■  Y 

art-etrvabr 

aeArf 

reRBbc 

tiv 

<  mogb  •  mogeffh  V  b  e  B  except  Bsup,  Barp,  Bway  ,  t  e  T 

Maximum  On  Ground:  For  all  bases  (except  super  pods,  AR  points,  and  waypoints)  and  time 
periods;  the  vehicle  parking  (refers  also  to  berthing)  required  for  transiting  or  terminating  direct 
delivery  missions  +  parking  for  transiting  and  terminating  transshipment  missions  +  shuttle 
mission  parking  (if  FOB  or  transshipment  POD)  +  chopped  vehicle  beddown  parking  (if  shuttle 
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beddown  base)  +  divert  base  parking  for  failed  refuelings  of  direct  delivery,  transshipment,  and 
backchannel  missions  +  tanker  aircraft  parking  (if  tanker  aircraft  and  tanker  beddown  base)  < 
available  MOG  *  MOG  efficiency. 

G.  VERIFICATION  AND  VALIDATION 

We  did  initial  validation  of  NRMOAS  using  NRMO  as  the  baseline.  We  constructed  a 
small  scenario  and  ran  it  through  both  NRMO  and  NRMOAS.  The  results  were  exactly  the 
same,  so  changes  made  to  NRMOAS  have  not  changed  the  basic  functioning  of  the  NRMO 
model.  Additionally,  we  found  no  mathematical  results  in  the  solution  file  that  would  indicate 
NRMOAS  was  behaving  in  any  unrealistic  fashion.  Ships  are  allocated  only  to  ports  and  travel 
only  on  sea  routes,  taking  the  appropriate  amount  of  time  to  transit  and  carrying  the  right 
amount  of  cargo.  We  recommend  further  more  stringent  validation  against  other  models 
currently  in  use.  In  particular,  we  recommend  a  comparison  with  MIDAS  as  follow  on 
research. 
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IV.  SCENARIOS 


We  ran  three  similar  scenarios  through  NRMOAS  and  FDE.  Each  scenario  and  the 
results  obtained  are  described  in  this  chapter.  Additionally,  we  ran  one  scenario  through 
NRMOAS  both  in  the  user-designating  mode  and  the  model-designating  mode.  These  results 
are  also  compared. 

A.  ASSUMPTIONS  AND  INFORMATION  COMMON  TO  ALL  SCENARIOS 

1 .  All  units  can  be  assumed  to  make  their  ALD. 

2.  All  passengers  are  moved  by  aircraft  only. 

3.  For  NRMOAS  runs,  all  bases  were  given  an  unlimited  supply  of  fuel.  FDE  does 
not  consider  the  amount  of  fuel  available  on  bases  as  a  separate  constraint.  Also, 
data  on  fuel  availability  was  generally  poor  in  that  most  airfields  and  ports  are 
considered  to  have  unlimited  fuel  capacity. 

4.  NRMOAS  assigns  lift  assets  to  units  in  order  to  minimize  the  weighted  sum  of 
late  and  undelivered  cargo  penalties  (Baker,  1997,  p.  55).  It  does  not  actually 
prioritize  units  except  in  the  sense  that  it  will  assign  assets  to  move  a  unit  with  an 
earlier  RDD  before  a  unit  with  a  lower  RDD.  FDE  prioritizes  units  as  a  function 
of  tonnage  and  the  inverse  of  the  square  of  the  unit  priority  time  the  RDD  (FDE 
URM  1998,  p.  3-1): 

unit  priority  =  / {tonnage ,  1  /( priority  *  RDD)2  } 

The  actual  function  is  not  given  in  the  URM  and  was  not  available  from  the 
contractor,  so  we  assumed  that  setting  all  unit  priorities  in  FDE  to  one  would 
allow  both  models  to  prioritize  in  the  most  similar  manner. 
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5.  Initial  NRMOAS  runs  were  done  on  a  PC  with  a  Pentium  Pro  processor,  a  3. 1 
GB  hard  drive  and  32  MB  of  RAM.  Additional  runs  were  done  on  an  IBM 
RS6000  workstation  with  1  GB  of  RAM,  and  a  second  PC  with  a  Pentium  II 
Processor  and  500  MB  of  RAM. 

6.  All  FDE  runs  were  done  on  a  Sun  SPARC  Work  Station  with,  224  MB  of 
physical  memory  and  425  MB  of  virtual  memory. 

7.  All  FDE  runs  used  the  following  parameters: 

a.  FDE  was  only  run  in  simple  mode.  This  is  a  deterministic  mode  where  input 
values  such  as  speed  were  fixed  at  their  expected  value.  No  variable  inputs 
were  used. 

b.  Minimizing  lateness  for  units  was  the  only  model  goal  selected. 

c.  FDE  was  told  to  stop  if  it  reached  twenty  consecutive  infeasible  solutions. 

8.  The  scenarios  ran  through  NRMOAS  and  FDE  were  originally  designed  as 
duplicates.  Nevertheless,  some  network  differences  occurred  due  to  the  data 
input  requirements  of  each  program,  (described  in  Chapter  IV,  Section  C). 
Additionally,  we  noted  some  discrepancies  in  unit  load  requirements  in  the  data 
sets  created  by  other  sources.  These  discrepancies  occurred  when  the  FDE  data 
files  were  built  separately  by  a  SETA  analyst  and  sent  to  the  Naval  Postgraduate 
School  for  use  (see  Chapter  IV,  Section  C).  We  documented  the  differences  for 
each  scenario. 

9.  Unit  closure  is  defined  as  receipt  of  100%  of  all  cargo  and  personnel. 


48 


B.  RESULTS 


1.  Scenario  #  1 

We  designed  this  scenario  to  give  a  baseline  for  comparison.  Movement  assets  are  sufficient  to 
meet  all  RDD’s.  It  consists  of  twenty-four  units  including  nine  Air  Force  flying  squadrons, 
one  Army  armored  division,  one  Army  mechanized  division,  one  Army  air  assualt  division, 
various  Army  combat  service  support  units  and  one  USMC  regimental  landing  team.  Total 
cargo  requirements  are  shown  below  in  short  tons: 


Bulk  Cargo:  210293 

Oversized  Cargo :  1 62500 

Outsized  Cargo  1 1 5250 

Pax:  156483 


Lift  assets  for  this  scenario  are  plentiful.  The  aircraft  and  ships  available  are  based  on 
J8/WAD’s  estimates  for  the  total  assets  that  the  United  States  could  mobilize  in  the  event  of  a 


Major  Theater  War.  The  assets,  as  well  as  their  availability  dates,  are  shown  below  in  Table  1. 


Asset 

Is 

Available 

Asset 

i 

7 

12 

15 

16 

20 

21 

25 

45 

65 

C5 

56 

10 

12 

15 

m 

Cl  7 

80 

11 

■ 

KC10 

32 

4 

KC135 

7 

IS 

NBC 

3 

12 

I 

24 

WBC 

22 

32 

WBP 

15 

1 

54 

BB 

1 

12 

40 

FSL 

8 

LASH 

8 

LMSR 

11 

H 

10 

RORO 

36 

■ 

8 

10 

Table  1.  This  table  shows  the  maximum  number  of  assets  that  would  be  available  for  use 
during  an  MTW.  It  includes  both  military  and  CRAF  air  assets,  as  well  as  merchant  marine 
shipping.  Naval  and  MPS  shipping  is  not  considered.  Day  1  is  the  first  movement  day.  NBC, 
WBC  and  WBP  refer  to  three  types  of  civilian  aircraft  in  the  Civil  Reserve  Aircraft  Fleet 
(CRAF).  They  are,  respectively;  Narrow  Body  Cargo,  Wide  Body  Cargo,  and  Wide  Body  Pax. 
Ship  types  are  defined  in  Chapter  Three,  Section  D. 


49 


Delivery  windows  ranged  from  a  minimum  of  15  days  to  a  maximum  of  45  days.  Differences 
from  NRMOAS  to  FDE  are;  NRMOAS  used  thirteen  source  nodes  while  FDE  used  only  six 
and  based  on  differences  in  data  input,  FDE  was  required  to  move  approximately  10%  less 
cargo. 

NRMOAS  showed  no  real  deviation  from  the  delivery  requirements  (see  Figures  3  and 
4).  99.8%  of  cargo  was  delivered  on  time,  as  were  100%  of  personnel.  95.8%  of  units  attained 
cargo  closure  and  100%  attained  personnel  closure  by  their  RDD  (see  Figures  7  and  8). 

FDE  was  unable  to  meet  delivery  requirements,  needing  16  days  beyond  the  latest  RDD 
to  deliver  all  cargo  (see  Figures  5  and  6).  Only  70.1%  of  units  attained  closure  with  cargo  by 
their  RDD  and  up  to  18  days  were  required  for  the  last  unit  to  receive  all  its  cargo.  Personnel 
deliveries  showed  similar  results,  with  only  83.3%  of  units  attaining  personnel  closure  by 
RDD.  Five  days  was  required  for  the  last  unit  to  receive  all  its  personnel  (see  Figures  8  and  9). 
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Percent  Cargo  Delivered  -  Actual  vs.  Required 
(NRMOAS  Scenario  1) 


Days 


- Actual 

Required 


Percent  Pax  Delivered  -  Actual  vs.  Required 
(NRMOAS  Scenario  1) 


Days 


Actual 

Required 


Figures  3  and  4.  These  graphs  show  the  actual  deliveries  plotted  against  the  requirements  for 
both  cargo  and  personnel.  The  heavy  line  represents  requirements,  while  the  thin  line  shows  the 
actual  deliveries.  All  cargo  was  delivered  within  45  days  and  all  personnel  were  delivered 
within  30  days.  The  large  spikes  on  the  required  deliveries  line  are  due  to  scenario  design. 

They  do  not  represent  an  actual  TPFDD,  but  rather  a  simplified  replication  developed  strictly 
for  comparison  of  the  two  models. 
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Percent  Cargo  Delivered  -  Actual  vs.  Required 

(FDE  Scenario  1) 


Days 


- Actual 

. Required 


Percent  Pax  Delivered  -  Actual  vs.  Required 
(FDE  Scenario  1) 


Days 


- Actual 

Required 


Figures  5  and  6.  FDE  was  able  to  deliver  all  personnel  before  the  final  RDD,  but  needed  16 
additional  days  to  deliver  all  cargo.  Cargo  delivery  reached  approximately  80%  of  requirements 
by  the  last  RDD  of  45  days. 
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Unit  Closure  -  Cargo 
(FDE  vs.  NRMOAS  -  Scenario  1) 
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Unit  Closure  -  Pax 
(FDE  vs.NRMOAS  -  Scenario  1) 
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Figures  7  and  8.  These  graphs  display  the  unit  closure  rates  in  terms  of  days  after  RDD. 
NRMOAS  achieved  on-time  personnel  closure  for  100%  of  units  and  cargo  closure  for  95.8%. 
In  the  one  case  that  NRMOAS  did  not  close  by  RDD,  2  days  were  required  for  the  unit  to  close. 
FDE  achieved  on-time  personnel  closure  for  83.1%  of  units  and  on-time  cargo  closure  for 


70.1%. 
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2. 


Scenario  #  2 


We  designed  this  scenario  to  test  the  abilities  of  both  programs  in  terms  of  achievement 
of  delivery  windows.  Units  used  and  delivery  windows  are  the  same  as  Scenario  1,  however 
there  was  a  significant  reduction  in  assets.  Assets  for  this  scenario  are  shown  in  Table  2: 


Table  2.  This  table  shows  the  number  of  assets  used  for  Scenario  #2.  The  number  of  assets 
eliminated  from  Scenario  1  is  shown  in  the  right  column. 


The  reduction  in  assets  had  a  significant  affect  on  NRMOAS’s  ability  to  make 
deliveries  on  time.  NRMOAS  required  an  additional  30  days  beyond  the  last  RDD  to  complete 
delivery  of  cargo,  while  an  additional  17  days  was  required  for  personnel  (see  Figures  9  and 
10).  Unit  closure  was  also  affected,  with  the  number  of  units  attaining  cargo  closure  by  RDD 
dropping  to  29.9%  and  the  number  attaining  on-time  personnel  closure  dropping  to  25%  (See 
figures  13  and  14). 

FDE  was  affected  by  the  reduction  in  assets  to  a  far  greater  degree  than  NRMOAS. 
FDE  required  40  additional  days  beyond  the  last  RDD  to  complete  delivery  of  cargo  and  1 1 
additional  days  for  personnel  (see  Figures  11  and  12).  On-time  delivery  rates  also  dropped 
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severely,  with  just  12.5%  of  units  receiving  all  their  cargo  and  20%  receiving  all  their 


personnel  by  their  RDD  (see  Figures  13  and  14). 


Percent  Pax  Delivery  -  Actual  vs.  Required 
(NRMOAS  Scenario  2) 


1  4  7  10  13  16  19  22  25  28  31  34  37  40  43  46  49  52  55  58  61  64  67  70  73 

Days 


- Actual 

— —  Required 


Figures  9  and  10.  The  affects  of  a  2/3  reduction  in  lift  assets  from  Scenario  lis  shown  here. 
Actual  deliveries  were  able  to  stay  ahead  of  required  deliveries  for  cargo  up  to  day  45,  the  last 
RDD.  Although  the  flow  of  cargo  and  personnel  remained  constant,  the  slope  of  the  actual 
delivery  line  indicates  a  much  slower  buildup  than  Scenario  1. 
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Figures  1 1  and  12.  The  reduction  in  assets  greatly  affects  FDE’s  ability  to  deliver  cargo  on 
time.  With  less  than  50%  of  the  cargo  required  delivered  by  day  45,  FDE  required  85  days  to 
move  all  units  into  theater.  Personnel  deliveries  showed  a  similar  trend,  with  less  than  75%  of 
personnel  arriving  by  day  45. 
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Unit  Closure  -  Cargo 
(FDE  vs.  NRMOAS  -  Scenario  2) 
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Figures  13  and  14.  Asset  reduction  severely  impacted  on-time  deliveries  of  both  models  but 
much  more  so  for  FDE.  NRMOAS  dropped  the  number  of  units  that  received  all  their  cargo  by 
RDD  to  29.2%  and  the  number  that  received  all  personnel  by  RDD  to  25%.  The  last  unit 
required  30  days  to  attain  cargo  closure.  FDE  showed  an  even  more  significant  reduction  in 
cargo  closure,  dropping  to  12.5%.  FDE  personnel  closure  dropped  to  20.83% 
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3. 


Scenario  #  3 


We  designed  this  scenario  to  test  each  program  using  a  larger  contingency.  It  consists 
of  sixty-one  units,  and  includes  one  Army  armored  division,  one  Army  mechanized  division, 
three  Army  mechanized  brigades,  two  Army  armored  cavalry  brigades,  one  Army  armor 
brigade,  three  Army  light  infantry  brigades,  two  Ranger  regiments,  two  Special  Forces  Groups, 
various  Army  combat  support  and  combat  service  support  units,  two  USMC  regimental  landing 
teams,  a  Maritime  Prepositioning  Fly-In-Echelon,  and  twenty-eight  Air  Force  flying  squadrons. 
Total  cargo  requirements  are  shown  below  in  short  tons: 


Bulk  Cargo:  417473 

Over  Sized  Cargo:  277018 

Out  Sized  Cargo  1733972 

Pax:  315575 


Assets  for  this  scenario  are  the  same  as  those  in  Scenario  #1  (see  Table  #1).  Delivery 
windows  ranged  from  a  minimum  of  15  days  to  a  maximum  of  45  days.  As  with  Scenarios  1 
and  2,  we  noted  several  differences  between  NRMOAS  and  FDE’s  data.  In  this  case, 
NRMOAS  used  fifteen  source  nodes  while  FDE  used  only  six,  and  again,  based  on  differences 
in  data  input,  FDE  was  required  to  move  approximately  14%  less  cargo  and  5%  more 
personnel. 

NRMOAS  was  able  to  deliver  100%  of  personnel,  but  only  94.2%  of  the  cargo  (Figures 
15  and  16).  The  5.8%  nondelivery  of  cargo  is  caused  by  a  NRMOAS  parameter  called 
“maxlate”.  “Maxlate”  is  a  user  defined  parameter  that  is  the  maximum  number  of  days  after  a 
unit’s  RDD  that  cargo  and  personnel  can  be  delivered.  If  cargo  cannot  be  delivered  by  this 
day,  it  is  not  delivered  at  all.  “Maxlate”  was  set  to  30  days  for  this  scenario.  In  this  case,  the 
unit  affected  was  moved  by  air,  had  an  RDD  of  45  days  and  received  only  52.2%  of  its  cargo. 
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The  additional  heavy  requirements  decreased  the  number  of  units  attaining  cargo 
closure  by  RDD  to  72.1%  and  the  number  attaining  personnel  closure  by  RDD  to  67.2%  (see 
Figures  19  and  20). 

Although  the  model  parameters  were  set  for  26  trial  solutions,  FDE  repeatedly  crashed 
after  obtaining  only  one  feasible  solution,  which  is  reported  here.  FDE  delivered  all  required 
cargo  and  personnel  within  65  days.  Had  a  30  day  cut-off  restriction  similar  to  NRMOAS’s 
“maxlate”  been  applied  to  FDE,  cargo  deliveries  would  still  have  exceeded  99%,  while 
personnel  would  have  dropped  to  96.8%  (see  Figure  17  and  18).  96.7%  of  units  achieved 
cargo  closure  of  30  days,  while  80.3%  of  units  attained  personnel  closure  within  the  same 
period.  Of  concern,  however,  are  the  on-time  delivery  statistics.  Only  48.9%  of  units  cargo 
closed  by  their  RDDs,  while  only  32%  of  the  personnel  closed  by  their  RDD. 
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Figures  15  and  16.  Increasing  the  amount  of  cargo  and  personnel  to  be  moved  did  not  greatly 
affect  the  overall  delivery  profile.  NRMOAS  still  remained  generally  ahead  of  its  requirements 
throughout  most  of  the  deployment.  100%  of  personnel  were  delivered,  but  only  94.2%  of 
cargo.  Similar  to  the  delivery  requirements  in  Scenario  1  and  2,  the  large  spikes  on  the  required 
delivery  line  are  a  reflection  of  the  simplified  TPFDD  used  in  this  scenario. 
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Percent  Cargo  Delivered  -  Actual  vs.  Required 

(FDE  Scenario  3) 


- Actual 

■  Required 
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Percent  Pax  Delivered  -  Actual  vs.  Required 
(FDE  Scenario  3) 
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Required 


Figures  17  and  18.  FDE  was  able  to  deliver  all  cargo  and  personnel  to  the  theater  of  operations. 
Even  the  addition  of  the  30  day  cut-off  requirement  found  in  NRMOAS  would  have  reduced  the 
delivery  of  cargo  by  only  0.1%  and  the  delivery  of  personnel  by  less  than  2%. 
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Unit  Closure  -Cargo 
(FDE  vs.  NRMOAS  -  Scenario  3) 
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Unit  Closure  -  Pax 
(FDE  vs.  NRMOAS  -  Scenario  3) 
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Figures  19  and  20.  The  large  amount  of  cargo  and  personnel  to  be  moved  in  Scenario  3  caused 
NRMOAS  to  drop  the  number  of  units  achieving  closure  by  RDD  to  72.1%  for  cargo  and  67.2% 
for  personnel.  In  both  cases,  90%  of  the  units  closed  within  2  days  of  their  RDD  s,  leaving  just 
three  units  needing  to  receive  deliveries  of  cargo  or  personnel.  All  personnel  were  delivered 
within  30  days;  however,  one  unit  never  received  its  full  requirement  of  cargo  because  it  could 
not  be  delivered  within  30  days  of  that  unit’s  RDD.  FDE’s  unit  closure  rate  also  dropped;  to 
45.9%  for  cargo  and  37.8%  for  personnel.  Additionally,  the  final  unit  to  close  with  cargo 
received  its  last  shipment  42  days  past  its  RDD.  Similarly,  the  final  unit  to  close  with  personnel 
received  it  last  delivery  32  days  after  its  RDD.  IN  all  scenarios  NRMOAS  produced  more 
favorable  closure  profiles  than  FDE. 
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4.  NRMOAS  Mode  Selection  Comparison 

As  discussed  in  Chapter  HI,  NRMOAS  can  be  run  in  two  different  modes:  User 
Select  Mode,  where  the  user  designates  which  mode  of  travel  each  unit  uses,  and  Model  Select 
Mode,  where  the  model  designates  which  mode  of  travel  the  unit  uses.  In  addition  to  the 
comparsion  with  FDE,  we  ran  Scenario  #3  in  the  NRMOA  model  select  mode.  The  only 
difference  in  the  scenarios  was  a  slight  deviation  in  RDDs  for  personnel.  Personnel  are  moved 
only  by  air;  therefore,  when  using  the  user  select  mode,  it  is  necessary  to  divide  those  units 
whose  cargo  moves  by  sea  into  two  line  id’s,  one  for  personnel  and  one  for  cargo.  In  doing 
this,  we  gave  the  personnel  an  earlier  RDD.  When  using  the  model  select  mode,  it  is  not 
necessary  to  split  the  units,  so  both  cargo  and  personnel  were  given  the  same  date. 

The  most  important  result  from  the  two  runs  is  that  in  the  model  select  mode, 
NRMOAS  delivered  100%  of  cargo  amd  personnel  to  the  theater  of  operations,  an 
improvement  over  the  94.3%  delivery  of  cargo  in  the  user  select  mode.  Additionally,  while 
on-time  delivery  rates  did  not  improve  greatly,  closure  rates  for  both  cargo  and  personnel  did. 
(see  Figures  21  and  22). 
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Unit  Closure  -  Cargo 
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Figures  21  and  22.  In  the  model  selection  mode  on-time  deliveries  for  cargo  increased  from 
72%  to  77%.  The  most  noticeable  change  however,  was  that  all  units  closed  within  19  days. 
On-time  delivery  of  personnel  showed  a  much  greater  increase,  from  67%  to  80%. 
Additionally,  all  personnel  closed  by  day  14,  a  14  day  decrease  from  NRMOAS  in  the  user 
select  mode.  (Note  that  the  graph  scales  start  at  50%.) 
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Figures  23  and  24  show  the  differences  in  how  cargo  was  moved.  The  only  major 
difference  is  in  bulk  cargo.  When  NRMOAS  selected  the  mode  of  movement,  significantly 
more  bulk  cargo  was  moved  by  air  than  by  sea. 
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Figures  23  and  24.  These  figures  show  the  amount  of  cargo  delivered  by  air  and  sea  under  full 
optimization  (Model  Select  mode)  and  partial  optimization  (User  Select  mode).  Amounts  of 
cargo  delivered  did  not  change  greatly,  with  exception  of  bulk  cargo.  NRMOAS  in  model 
select  mode  found  airlift  a  more  effective  way  to  move  bulk  cargo.  Percentages  are  calculated 
as  the  percentage  of  cargo  delivered  ,  vice  required.  This  is  to  account  for  the  undelivered  cargo 
from  Scenario  3. 

We  also  discovered  a  difference  in  the  usage  of  the  Cl 7,  WBC  and  WBP  aircraft.  In 
the  user  select  mode,  unit  personnel  and  cargo  were  moved  as  separate  line  id’s  with  different 
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RDD’s,  normally  earlier  for  the  personnel  than  for  the  cargo.  Because  more  personnel  were 
required  to  arrive  in  theater  than  the  use  of  CRAF  assets  would  allow,  the  C17  was  used  to 
move  a  large  amount  of  personnel  instead  of  cargo.  While  this  is  not  the  preferred  use  of  a 
C17,  the  model  responded  in  the  way  it  should  have,  using  the  best  assets  available  to  achieve 
its  RDD’s.  When  used  in  model  select  mode,  unit  personnel  and  cargo  had  the  same  RDD’s, 
which  allowed  a  later  arrival  time  for  personnel  than  from  the  user  select  mode  scenario. 
Again,  the  model  responded  as  it  should,  using  the  C 17  to  carry  cargo  and  saving  the  personnel 
for  the  WBP.  Thus,  the  C 17  was  used  less  frequently,  but  more  efficiently  in  the  model  select 
mode.  The  WBC  aircraft  was  also  used  more  frequently  by  the  model  select  mode,  carrying 
bulk  cargo  that  was  initially  moved  by  sea. 

C.  OVERALL  COMPARISONS 

1.  Data  Preparation 

Data  preparation  in  NRMOAS  requires  some  knowledge  of  GAMS  and  its 
requirements  for  file  formatting.  GAMS  files  are  written  as  text  files,  so  once  the  user  is 
comfortable  with  these  aspects  of  preparation,  the  process  is  fairly  straightforward.  Of  the  five 
data  input  files,  calc.inc  requires  no  alteration  from  scenario  to  scenario.  The  calculations  it 
makes  remain  the  same  regardless  of  scenario  specfics.  Scenario.inc  contains  some  scenario 
information  such  as  aerial  refueling  points,  tanker  beddown  points  and  crew  staging  bases; 
however,  we  did  not  use  these  factors  in  the  scenarios,  so  that  file  also  remained  unchanged. 
Acdat.inc  contains  asset  specific  information  and  requires  an  update  when  the  type  or 
availability  of  assets  changes.  Routes.inc  contains  network  data  and  therefore  must  be  updated 
with  every  new  scenario.  Gamsagg.set  also  differs  for  every  scenario  as  it  contains  all  unit 
data,  to  include  load  and  delivery  time  windows,  and  all  base  data  including  locations  and 
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capabilities.  NRMO  can  generate  the  unit  and  carrier  load  information  portions  of  gamsagg.set 
using  an  Air  Force  TPFDD  and  the  Air  Flow  Model  (AFM),  however  the  carrier  capacity  data 
generated  in  this  fashion  contains  only  aircraft  data  and  is  not  useful  to  NRMO  AS.  Instead, 
TPFDD  data,  as  well  as  aircraft  and  ship  capacity  data,  must  be  input  by  hand. 

For  NRMOAS,  resolution  of  TPFDD  data  can  be  done  to  whatever  degree  the  user 
desires.  For  these  scenarios,  resolution  was  down  to  the  squadron  level  for  Air  Force  units,  the 
brigade  and  division  level  for  Army  units  and  the  regimental  level  for  USMC  units.  Once  a 
base  file  is  created,  changes  can  be  made  fairly  rapidly  to  reflect  new  scenarios. 

FDE  data  files  are  built  and  edited  via  the  GUI.  No  preprocessor  is  available,  so 
TPFDD  data  must  be  input  manually.  As  with  NRMOAS,  the  level  of  resolution  of  the 
TPFDD  can  be  determined  by  the  user;  however,  most  existing  FDE  units  are  squadron-, 
brigade-  or  division-sized. 

FDE  GUI  is  slow  and  tedious.  It  requires  most  entries  to  be  made  one  at  a  time  and 
does  not  allow  minor  changes  to  be  made  easily.  For  example,  to  reduce  the  number  of  C5’s 
available  for  use  on  a  given  day  from  56  to  20,  the  user  has  two  options:  either  delete  26  C5’s 
one  by  one,  confirming  each  deletion  via  a  pop-up  window;  or  delete  all  the  C5’s  and  add  back 
in  the  20  the  user  wants.  A  much  simpler  method  would  be  to  allow  the  user  to  highlight  and 
delete  more  than  one  item  at  a  time.  Similar  editing  options  through  out  all  screens  make 
creating  or  changing  existing  files  very  slow. 

The  most  difficult  part  of  building  the  FDE  data  file  is  setting  up  the  network.  One 
problem  we  encountered  while  building  the  networks  is  that  paths  from  a  source  node  to  a  sink 
node  that  contain  more  than  four  links  cause  FDE  to  crash.  This  severely  limits  the  realistic 
geographical  depiction  of  a  deployment  network.  For  example,  it  is  impossible  to  portray  a 
realistic  sea  route  from  a  seaport  in  the  Gulf  of  Mexico  to  the  port  of  Ad  Damman,  on  the  east 
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coast  of  Saudi  Arabia  with  only  four  links.  Additionally,  FDE  had  trouble  finding  solutions 
when  the  network  was  composed  of  multiple  sources  with  small  amounts  of  cargo.  This 
requires  that  the  network  be  built  using  a  smaller  number  of  aggregate  embarkation  bases.  In 
the  case  of  these  comparison  scenarios,  NRMOAS  used  12  or  13  source  nodes,  while  FDE 
used  6. 

In  most  cases,  FDE  files  are  built  using  the  fort.l  legacy  file,  which  contains  extensive 
unit  and  carrier  information.  The  fort.l  file  serves  as  a  shell  from  which  desired  scenarios  are 
built.  In  the  absence  of  the  fort.l  file,  building  files  can  be  extremely  challenging.  In  fact, 
building  files  from  scratch  is  highly  discouraged  by  experienced  FDE  users.  We  encountered 
numerous  problems  during  the  course  of  this  thesis  while  building  FDE  data  sets  from  scratch. 
Eventually,  we  used  data  files  that  were  built  by  a  SETA  Corporation  analyst,  using  the  fort.l 
file.  We  encountered  some  discrepancies  in  the  unit  load  requirements  data,  which  accounted 
for  the  differences  in  cargo  requirements  between  the  NRMOAS  and  FDE  runs. 

2.  Cargo  Delivery 

In  all  but  one  case,  both  models  were  eventually  able  to  deliver  all  cargo  and  personnel 
to  the  theater  of  operations.  The  greatest  difference  between  the  models  was  in  percentages  of 
on-time  deliveries.  Here,  NRMOAS  was  clearly  superior.  Overall,  high  and  low  on-time 
delivery  rates  are  shown  in  Figure  25. 
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Figure  25  This  graph  is  a  compilation  of  NRMOAS ’s  and  FDE’s  delivery  rates  over  all  three 
scenarios.  The  overall  column  includes  the  total  number  of  units  delivered  on-time  over  all 
three  scenarios.  High  and  low  columns  indicate  the  maximum  and  minimum  on-time  rates 
achieved. 


While  there  are  may  be  numerous  factors  that  contribute  to  the  differences  in 
NRMOAS’s  and  FDE’s  results,  two  of  the  major  ones  are  first,  asset  utilization  rates  and 
second,  initial  allocation  methods.  Both  NRMOAS  and  FDE  require  that  each  lift  asset  be 
given  a  utilization  rate.  This  “ute  rate”,  determines  how  many  hours  a  day  that  a  certain  asset 
can  be  flown  or  sailed.  Utilization  rates  used  in  all  three  scenarios  are  shown  in  Table  3. 


Asset 

C5 

C17 

KC10 

KC135 

NBC 

WBC 

WBP 

Ute  Rate 

10.87 

15.15 

12.5 

6 

10 

10 

10 

Table  3.  Utilization  rates  determine  the  number  of  hours  per  day  that  an  aircraft  can  be  flown. 
Ship  utilization  rates  have  been  omitted,  because  ships  are  not  subject  to  crew  rest  or  down  time 
when  traveling  and  therefore  operate  24  hours  a  day.  NRMOAS  uses  this  data  in  hours  per  day, 
whereas  IDE  converts  to  fractions  of  a  day. 


NRMOAS  sums  the  number  of  hours  an  aircraft  is  flown  and  balances  it  with  that 
aircraft’s  utilization  rate  to  determine  if  the  aircraft  can  fly  a  subsequent  mission.  Flight  times 
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are  balanced  over  a  user  determined  period  of  time,  which  we  set  to  5  days.  This  allows  the 
model  a  certain  amount  of  flexibility  when  assigning  aircraft  to  missions. 

FDE  takes  the  same  figure,  as  a  fraction  of  24  hours.  It  then  multiples  this  number  by 
the  total  amount  of  assets  available  and  uses  the  remaining  nui  >er  of  aircraft  24  hours  a  day. 
This  information  is  not  documented  anywhere,  but  was  expla.  ed  by  '  ;e  SETA  analyst  who 
assited  us  by  building  data  files  No  explanation  of  how  FDE  handles  ground  time  was  given. 
Based  on  this  reduction  method,  if  there  are  56  C5’s  available  on  day  one,  FDE  will  only  use 
26  of  them  to  account  for  their  utilization  rate  of  0.4529.  FDE  always  rounds  this  number  up 
so  the  user  never  ends  up  with  0  aircraft  due  to  utilization  rate.  This  method  dramatically 
reduces  FDE’s  available  lift  assets.  Figure  26  shows  the  differences  in  aircraft  available  to 
NRMOAS  and  FDE. 


Available  Aircraft  vs.  Aircraft  Utilized 


■  Available 
□NRMOAS 
□  FDE 


Figure  26.  Due  to  the  way  that  FDE  uses  the  utilization  rate,  it  effectively  starts  each 
deployment  with  one  half  of  the  number  of  aircraft  available  to  NRMOAS.  This  allows 
NRMOAS  to  move  more  cargo  faster,  making  it  easier  to  meet  its  RDD  requirements.  Note  that 
in  the  case  of  the  C 17  aircraft,  FDE  did  not  follow  its  own  algorithm.  We  could  not  find  a 
reason  for  this. 
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Another  contributing  factor  in  FDE’s  difficulties  meeting  delivery  window 
requirements  is  its  allocation  algorithm.  FDE’s  allocation  is  done  as  a  biased  stochastic 
assignment  of  lift  assets  directly  proportional  to  the  tonnage  requirements  of  the  unit  and 
inversely  proportional  to  the  square  of  the  unit’s  priority  and  its  required  arrival  time  (see 
Chaper  IV,  Section  B).  Each  new  trial  is  a  new  random  number  sequence  that  generates  a  new 
allocation  of  lift  assets.  This  heuristic  is  designed  simply  to  give  a  feasible  starting  point. 
(FDE  URM,  1998,  p.  3-16)  A  close  examination  of  one  unit  which  arrived  on  time  with 
NRMOAS  and  15  days  late  with  FDE  shows  the  flaws  in  this  algorithm.  The  unit  is  an  Army 
armored  division  with  a  RDD  of  45  days.  Its  FDE  asset  allocation  is  shown  in  Table  4: 


Number  Allocated 

Asset 

Day  Asset  Became  Available 

1 

WBP 

12 

1 

WBP 

20 

2 

LASH 

15 

1 

RORO 

25 

4 

LM  SR 

45 

1 

LASH 

45 

2 

BB 

65 

Table  4.  This  table  shows  the  allocation  of  assets  to  an  Army  armored  division  that  arrives  15 
days  past  its  RDD  (Scenario  1).  Because  of  the  random  nature  of  the  initial  allocation  heuristic, 
the  unit  was  not  allocated  sufficient  assets  to  arrive  in  theater  on  time.  NRMOAS  ‘s  solution 
moved  the  Army  division  on  7  LMSR’s  and  1 1  RORO’s,  with  closure  on  day  43. 


Based  on  lift  capabilities  and  tonnage  requirements,  the  unit  did  not  receive  enough 
assets  to  make  its  RDD.  Because  the  allocation  is  based  on  a  random  number,  this  type  of 
situation  can  repeat  itself  during  any  trial  solution  for  any  type  of  unit.  This  would  make  it 
extremely  difficult  to  determine  whether  a  certain  type  of  unit  consistently  slows  the  entire 
deployment,  or  uses  up  all  of  one  type  of  asset. 

Like  NRMO,  NRMOAS  allocates  assests  based  on  minimizing  the  weighted  sum  of 
late  and  undelivered  cargo  penalties,  subject  to  restrictions  such  as  asset  balance,  asset  payload, 
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and  port  and  airfield  capacity.  In  essence,  NRMOAS  sends  the  assets  to  where  they  will  have 
the  most  positive  effect  on  the  overall  deployment  schedule.  In  NRMOAS’s  case,  the  Army 
armored  division  was  loaded  on  7  LMSR’s  and  11  RORO’s,  in  combination  with  three  other 
units  with  a  similar  RDD  and  destination.  It  arrived  on  day  43.  Because  NRMOAS  gives  an 
optima]  utilization  of  assets,  any  shortfalls  or  slowdowns  can  be  traced  to  their  true  cause, 
rather  than  being  due  to  a  poor  random  draw. 

3.  Speed  of  Computation 

Run  time  comparisons  for  the  different  scenarios  are  shown  in  Table  5. 


Scenario 

NRMOAS 

Platform  Used 

Run  Time 

FDE 

Platform  Used 

Run  Time 

1 

PC,  32  MB  RAM 

38.96  min 

Sun  SPAC 

2 

PC  32  MB  RAM 

33.11  min 

Sun  SPARC 

3 

PC,  500  MB  RAM 
IBM  RS6000,  595H 

3  hr,  49  min 

1  hr,  12  min 

Sun  SPARC 

■ 

4 

IBM  RS6000,  595H 

2  hr,  10  min 

Not  Compared 

*  Only  resulted  in  one  feasible  solution  before  FDE  crashed. 


Table  5.  The  table  show  the  run  times  for  each  scenario  and  what  type  of  platform  it  was  run 
on.  For  NRMOAS,  memory  allocation  was  more  of  a  limiting  factor  than  processor  speed.  Run 
times  for  FDE  are  based  on  26  trial  solutions  except  where  noted. 


NRMOAS,  in  searching  for  an  optimal  answer,  requires  significantly  greater 
computation  time  than  FDE.  The  FDE  URM  states  (without  proof  and  without  precedent  in 
the  operations  research  literature)  that  if  FDE  makes  between  25  and  75  trial  runs,  the  resulting 
solution  will  be  very  close  to  a  global  optimum  (FDE  URM,  1998,  p.  3-9).  That  would 
increase  the  run  times  for  FDE  by  approximately  three  times;  however,  whenever  any  number 
of  trial  runs  over  26  was  requested,  FDE  crashed  after  number  26,  requiring  us  to  limit  the 
number  of  trial  runs.  In  the  case  of  Scenario  3  FDE  found  1  feasible  solution  and  then  crashed 
during  trial  2.  To  avoid  crashing,  we  simply  set  the  number  of  trial  runs  to  1. 
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4.  Ease  of  Analysis  of  Output 

The  NRMOAS  output  file  can  be  formatted  by  the  user  to  display  whatever  data  is 
desired.  The  user  can  suppress  information  that  is  not  wanted,  as  well  as  display  any  additional 
information  required.  The  output  file  gives  a  detailed  breakdown  of  cargo,  carrier,  base,  route 
and  unit  information,  throughout  the  course  of  the  deployment.  The  output  file  is  constructed 
as  comma-delimited  input  to  a  spreadsheet.  This  makes  the  output  easy  to  work  with  since 
most  users  should  have  access  to  and  some  knowledge  of  spreadsheet  operations.  For 
example,  all  graphs  depicting  NRMOAS  delivery  information  were  created  from  the  output  file 
using  Excel©  spreadsheet  utilities.  NRMOAS ’s  output  report  also  allows  easy  infrastructure 
analysis.  For  example,  the  user  can  determine,  using  the  output  report,  which  bases,  routes  and 
assets  were  the  most  heavily  used. 

FDE  files  contain  a  large  amount  of  information  in  a  series  of  pre-formatted  files  (see 
Appendix  A  for  detailed  file  descriptions).  As  with  NRMOAS,  these  files  give  a  detailed 
breakdown  of  cargo  movement,  carrier  assignment,  and  base  and  route  utilization.  They  are 
printed  as  space-delimited  text  that  can  be  used  as  standalone  reports  or  imported  into 
spreadsheets.  FDE  also  contains  files  that  allow  the  user  to  request  and  view  multiple  graphs, 
to  include  model  goal  satisfaction  and  percent  of  units  delivered  by  day.  If  the  user  desires 
information  in  some  other  format  than  that  which  FDE  is  designed  to  display,  it  must  be 
created  by  hand  from  the  output  files.  As  with  NRMOAS,  this  can  be  done  using  a  standard 
spreadsheet,  although  a  significant  amount  of  data  manipulation  is  required.  FDE’s  high  level 
of  aggregation  and  limited  ability  to  represent  actual  deployment  networks  makes  it  impractical 
to  use  for  detailed  infrastructure  analysis. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  Force  Deployment  Estimator  is  a  low  resolution  model  that  can  be  used  to  give 
quick  lower  bound  solutions  to  generic  force  mobility  questions.  FDE’s  usefulness  as  a  tool 
for  detailed  real  world  analysis,  however,  is  severely  hampered  by  its  inadequete  network 
representation.  The  limitations  of  at  most  four  links  in  a  path  and  the  high  level  of  aggregation 
required  for  embarkation  nodes,  make  detailed  analysis  of  actual  deployment  routes 
impossible..  Exceeding  these  limitations  causes  the  model  to  crash.  To  use  FDE,  a  deployment 
network  must  be  tailored  to  FDE’s  capabilities.  This  limits  FDE’s  use  to  certain  “off-the- 
shelf’  scenarios  that  are  known  to  work.  FDE’s  high  level  of  aggregation  also  applies  to 
airfield  and  port  services.  Fuel  capacities  are  not  accounted  for  and  MOG  is  generally 
unconstrained,  assumptions  that  decrease  FDE’s  usefulness  as  a  detailed  analysis  tool. 

When  comparing  similar  scenarios,  NRMOAS  consistently  out-performed  FDE, 
achieving  superior  on-time  delivery  rates  both  for  cargo  and  personnel.  NRMOAS  allows  the 
user  to  input  any  network  or  deployment  situation  and  receive  an  optimal  solution  and  allows  a 
high  degree  of  resolution  both  in  network  and  infrastructure  design.  This  detail  makes 
NRMOAS  well-suited  to  in-depth  analysis  of  unit  movement,  route  and  base  use,  and  asset 
utilization.  NRMOAS ’s  solution  gives  the  user  the  most  efficient  mix  of  available  assets  and 
routing  required  to  complete  a  deployment.  This  allows  the  user  to  focus  on  key  areas  of 
analysis,  without  the  concern  that  the  results  are  based  on  a  random  allocation.  Because 
NRMOAS  can  be  run  on  any  GAMS  capable  computer,  it  has  a  degree  of  portability  that  is  not 
found  with  FDE,  which  is  designed  to  run  on  SUN  SPARC  systems.  NRMOAS  would  benefit 
from  the  inclusion  of  a  more  user-friendly  interface.  Additionally,  NRMOAS  lack  of  ability  to 
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represent  stochastic  events  could  limit  its  applications  in  some  areas. 


B.  RECOMENDATIONS 

If  FDE  is  to  be  retained  as  a  tool  for  analysis  in  J8AVAD,  it  requires  major 
improvements  in  its  ability  to  accurately  represent  deployment  networks.  The  current 
limitations  of  at  most  four  links  in  a  path  and  FDE’s  apparent  inability  to  handle  multiple 
source  nodes  with  small  amounts  of  cargo  must  be  corrected  for  FDE  to  be  at  all  useful  for 
analyzing  actual  deployment  networks.  The  extreme  difficulty  in  building  files  from  scratch 
must  also  be  corrected.  Additionally,  the  initial  allocation  alogorithm  should  be  looked  at  in 
an  effort  to  improve  its  ability  to  assign  assets.  Furthermore,  minor  improvements  to  the  GUI 
would  make  it  much  more  tolerable.  Finally,  unsubstantiated  claims  of  global  optimality  must 
be  retracted. 

NRMOAS’s  superior  performance  in  on-time  deliveries  and  higher  level  of  resolution 
for  networks  and  infrastructure  make  it  a  better  tool  for  detailed  analysis  than  FDE.  J8AVAD 
should  utilize  NRMOAS  for  use  in  answering  detailed  mobility  questions  concerning  actual 
deployment  networks  and  infrastructure  questions.  While  on-site  testing  by  J8/WAD  is 
recommended,  we  believe  that  NRMOAS  will  give  J8/WAD  an  added  dimension  in  mobility 
analysis  that  it  currently  does  not  possess  with  FDE. 
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APPENDIX  A  -  ADDITIONAL  FDE  DETAILS 


A.  OUTPUT  FILES 

1 .  “fort.2”,  Solution  File.  This  contains  a  rehash  of  all  input  data,  a  listing  of  how  well  FDE 
met  its  user  assigned  goals  and  all  of  the  initial  carrier  allocation  data.  It  is  written  in  a  format  to 
allow  it  to  be  printed  and  read  as  is.  (FDE  URM,  1998,  p.3-25) 

2.  “fort.3”,  History  File.  This  contains  details  on  all  the  events  that  occurred  during  the 
deployment  simulation.  It  is  divided  into  five  sections: 

a.  Section  1  contains  the  date  and  time  the  solution  was  found. 

b.  Section  2  contains  the  path  and  unit  data  for  link  in  the  route  network. 

c.  Section  3  lists  carrier  data  and  assigns  each  carrier  an  index  number.  It  is  designed 
for  use  as  a  reference. 

d.  Section  4  is  a  state  definition  table  that  is  also  designed  for  use  as  a  reference. 

e.  Section  5  shows  the  timing  for  each  event  that  occurs  during  the  simulation. 

(FDE  URM,  1998,  p.  3-25) 

3.  “fort.  10”,  Bar  Chart  Data  File.  This  file  holds  the  data  to  produce  bar  charts  which  can  be 
used  to  display  the  following  information: 

a.  A  lift  objectives  chart  which  shows  how  close  the  program  came  to  meeting  its 
required  goals. 

b.  A  closure  histogram  which  displays  the  closure  for  priority  one  units 

c.  A  dispersion  histogram  which  displays  the  closure  of  priority  one  units. 

d.  A  cost  histogram  which  displays  the  frequency  of  costs  associated  with  unit 


movements. 


e.  A  re-allocation  histogram  which  shows  the  re-allocation  of  units.  This  chart  is  only 
available  when  minimization  of  re-allocation  is  selected  as  a  program  goal. 
(FDEURM,  1998,  p.  3-28) 

4.  “fort.  11”,  Line  Graph  Data  File.  This  file  contains  the  data  needed  to  draw  line  charts. 

These  line  charts  can  be  used  to  display  the  arrival  profile  of  each  unit’s  cargo  and  personnel 
over  time.  (FDE  URM,  1998,  p.  3-28) 

5.  “fort.  12”,  Missions  on  Ground  file.  The  first  portion  of  this  file  lists  the  index  values  of  each 
carrier  and  each  node.  The  rest  of  the  file  gives  the  numbers  of  each  carrier  type  at  each  node, 
per  unit  time.  (FDE  URM,  1998,  p.  3-29) 

6.  “fort.  13”,  Equipment  on  Ground  File.  The  first  part  of  the  file  lists  the  index  values  for  load 
types,  node  names  and  unit  names.  The  rest  of  the  file  gives  the  tons  of  cargo  moved  through 
each  node,  per  unit,  per  unit  time.  (FDE  URM,  1998,  p.  3-30) 

7.  “fort.  14”,  Fraction  of  Craft  Utilized  File.  This  file  first  lists  index  values  for  the  carriers. 

The  rest  of  the  file  gives  the  number  of  carriers  used  by  each  unit  per  unit  time.  (FDE  URM, 
1998,  p. 3-31) 

8.  “fort.  15”,  Unit  Craft  Utilized  File.  The  gives  the  number  of  carriers  used  by  each  unit  per 
unit  time.  (FDE  URM,  1998,  p.  3-31) 

9.  “fort.  16”,  Unit  Fraction  of  Actual  Craft  Utilized  File.  The  first  part  of  this  file  lists  index 
values  for  the  carriers  and  units.  The  rest  of  the  file  gives  the  percentage  of  each  type  of  carrier 
used  per  unit  per  unit  time.  (FDE  URM,  1998,  p.  3-32) 

10.  “fort.75”,  Consolidated  Graphics  File.  This  is  simply  a  consolidation  of  files  “fort.  12” 
through  “fort.  16”.  This  file  is  no  longer  needed  as  a  separate  file,  but  is  still  included  in  Version 
3.1.  (FDEURM,  1998,3-33) 
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B.  AIRCRAFT  LOADING  ALGORITHMS 


The  following  rules  and  definitions  apply  to  all  algorithms: 

1 .  Class  1  carriers  carry  personnel  only  -  no  cargo. 

2.  All  carriers  wait  at  a  node  for  a  full  load  if  the  current  partial  load  contains  personnel 
only  and  there  are  more  passengers  arriving.  The  carrier  will  wait  only  if  waiting  will  improve 
the  closure  time  of  the  unit.  If  waiting  will  extend  the  arrival  time  of  the  unit,  the  carrier  will 
not  wait  for  the  arriving  passengers. 

3.  All  cargo  aircraft  (Class  2  carriers)  can  carry  bulk  cargo. 

4.  %  Oversized  -  The  proportion  of  the  total  cargo  weight  in  short  tons  which  is  oversized 
cargo,  when  the  load  includes  outsized  cargo.  The  percentage  is  unit  specific. 

5.  %  Outsized  -  The  proportion  of  the  total  cargo  weight  in  short  tons  which  is  outsized 
cargo,  when  the  load  also  includes  oversized  cargo.  This  percentage  is  unit  specific. 

(FDEURM,  1998,  p.  3-16) 

FDE  considers  five  separate  loading  cases. 

Case  1:  Load  consists  of  bulk,  over  and  out-sized  cargo. 

Total  Load  =  carr_over  *  carr_%over  +  carr_out  *  carr_%out 

100  100 

Max  Outsized  Load  =  carr_out  *  carr_%out 
100 

Max  Oversized  Load  =  carr_over  *  carryover 

100 

Max  Bulk  Load  =  Total  Load  -  carr_over  -  carr_out 
Max  Passengers  =  carr_pax 
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Case  2:  Load  consists  of  bulk  and  out-sized  cargo. 


Total  Load  =  carr_out 

Max  Outs i zed  Load  =  carryout 

Max  Bulk  Load  =  Total  Load  -  carr_out  already  loaded 
Max  Passengers  =  carr__pax 

Case  3:  Load  consists  of  bulk  and  over-sized  cargo. 

Total  Load  =  carryover 

Max  Outsized  Load  =  carryover 

Max  Bulk  Load  =  Total  Load  -  carr_over  already  loaded 
Max  Passengers  =  carr_pax 

Case  4:  Load  consists  of  bulk  cargo. 

Total  Load  =  carr_bulk 
Max  Bulk  Load  =  Total  Load 
Max  Passengers  =  carr_pax 

Case  5:  Load  consists  only  of  passengers.  The  equations  used  are  shown  below: 

Max  Passengers  =  carr_paxO 

(FDEURM,  1998,  p.  D-l) 

The  following  logic  loops  are  used  to  determine  specific  amounts  of  cargo  moved: 
Amount  of  Outsized  Cargo  Moved: 

if  (min  (unit„over,  carryover)  =  0) ,  then 
out_moved  =  min (unit_out , carr_out ) 

else 

over_moved  =  min  (unit_out,  carr_%out  /  100) 

end  if 
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Amount  of  Oversized  Cargo  Moved: 


if  (min  (unit_out,  carr_out)  =  0),  then 

over_moved  =  min (uni t_over, carryover ) 

else 

over_moved  =  min  (unit_over,  carryover  /  100) 

end  if 


Amount  of  Bulk  Cargo  Moved: 

if  (min  (unit_out,  carryout)  =  0),  then 

if  (min  (unit_out,  carr_out)  =  0) ,  then 

bulk_moved  =  min (unit_bulk,  carr__bulk) 

else 

bulk_moved  =  min  (unit_bulk,  (carr_over-carr_jDulk) 

endif 

else 

if  (min  (unit_out,  carr_out)  =  0),  then 

bulk_moved  =  min (unit_bulk,  (unit__out,  carr_out)  ) 

else 

bulk_moved  = 

min  (unit__bulk,  (  (carr-out*carr_%out  + 
carr_over*carr_%over)  /  100)  - 
unit_out  -  unit_over) 

endif 

endif 

Number  of  Passegers  Moved: 

if  (over-moved  and  out_moved  =0  and  bulk_moved  =0),  then 
pax  =  moved  =  min (unit_pax,  carr_pax0) 

else 

pax  =  moved  =  min  (unit_pax,  carr_pax) 

endif 

(FDE  URM,  1998,  p.  D-3) 


C.  MODELING  ASSUMPTIONS 

1.  All  arcs  are  bi-directional.  Delivery  arcs  may  be  used  for  re-assignment,  but  re-assignment 
arcs  may  not  be  used  for  delivery. 

2.  Carriers  are  assigned  to  unit  source  nodes.  Each  carrier  will  move  all  of  an  assigned  unit’s 
cargo  and  personnel  before  it  is  re-assigned. 
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3.  Carriers  that  do  not  allow  units  to  meet  their  required  delivery  dates  will  not  be  assigned  to 
that  unit. 

4.  Since  there  are  a  limited  number  of  carriers  that  can  carry  out-sized  cargo,  they  will  not  be 
assigned  to  carry  sustainment  (normally  bulk)  cargo  until  all  out-sized  cargo  has  been  moved. 

5.  Carrier  re-assignment  is  based  on  minimizing  the  following: 

Q  =  Active  Carriers  *  Re-allocation  Days  *  (Goal  Time  -  Current  Time)  * 

Unit  Priority  /  Total  Tonnage  Left 

6.  Personnel  only  carriers  wait  at  nodes  until  they  are  full  or  no  more  personnel  are  enroute  to 
that  node. 

7.  Unit  cargo  that  arrives  from  different  sources  can  be  aggregated  upon  arrival  to  a  common 
node. 

8.  Unit  arrival  is  defined  as  delivery  of  100%  of  personnel  and  cargo. 

9.  Nodes  and  links  may  be  degraded  by  enemy  action. 

10.  Mine  fields  do  not  affect  air  links. 

11.  Carriers  cannot  anticipate  when  a  full  node  will  have  space  to  service  them.  Therefore, 
loaded  carriers  at  a  full  node  will  simply  wait  until  they  can  be  unloaded  and  empty  carriers  will 
not  go  to  full  a  node  until  it  has  room. 

12.  If  the  variable  input  mode  is  used,  all  variables  are  statistically  independent. 

(FDE  URM  ,  1998,  p.  A-l) 


82 


APPENDIX  B  -  ADDITIONAL  NRMO  DETAILS 

A.  INPUT  FILES 

1.  Gamsagg.set.  Gamsagg.set  is  designed  to  work  with  a  pre-processor  program,  but  is  also 
fully  functional  as  a  stand  alone  file.  The  pre-processor  takes  line  information  from  the  TPFDD 
and  aircraft  capacity  data  from  files  contained  in  the  Airlift  Flow  Model  (AFM),  the  main 
simulation  used  by  the  Airlift  Mobility  Command  and  combines  them  into  a  format  usable  by 
NRMO.  For  users  with  a  non-Air  Force  TPFDD,  or  users  without  AFM,  the  required 
information  can  be  hard  wired  into  gamsagg.set  with  no  degradation  of  capabilities.  For  this 
analysis,  NRMO  was  used  with  hardwired  information.  Gamsagg.set  first  lists  all  aircraft  and 
all  bases  which  make  up  the  model.  Bases  are  broken  down  into  embarkation  bases,  forward 
operating  bases,  points  of  departure,  enroute  bases,  aerial  refueling  points,  recovery  bases  and 
supemodes  (aggregate  bases).  Base  locations  are  input  using  longitude  and  latitude.  Airfield 
capacity,  in  terms  of  Maximum  on  Ground  (MOG)  and  fuel  available  are  also  included. 
Additionally,  this  file  contains  all  the  unit  data  that  would  be  taken  from  a  TPFDD,  to  include 
unit  identification,  point  of  origin,  point  of  departure,  cargo  demand  available  to  load  date,  and 
required  delivery  date. 

2.  Routes.inc.  Routes.inc  sets  up  the  network  over  which  the  deployment  is  carried  out.  It 
identifies  deployment  routes,  backchannel  (re-deployment)  routes  and  adjacent  nodes  and  arcs. 
In  addition,  it  defines  which  aircraft  can  travel  over  which  arcs.  This  file  also  is  used  to 
designate  arcs  as  Category  1,  an  AMC  categorization  that  is  given  to  flights  over  water.  An 
aircraft  flying  a  Category  1  arc  must  carry  an  extra  10%  fuel. 

3.  Scenario.inc.  Scenario.inc  contains  items  specific  to  a  given  scenario.  This  includes  the 
breakdown  of  aerial  refueling  points,  tanker  bed  down  sites,  and  crew  staging  bases.  It 
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delineates  between  military  and  Civil  Reserve  Air  Fleet  (CRAF)  aircraft.  It  identifies  those 
aircraft  that  can  be  refueled  by  tankers,  as  well  as  what  aerial  refueling  points,  bed  down  bases, 
and  forward  operating  bases  can  be  used  by  which  aircraft  and  which  routes.  Scenario  also  sets 
the  theater  recovery  policy;  “allrec”,  meaning  always  use  recovery  routes,  “somerec”  meaning 
sometimes  use  recovery  routes  or  “norec”  meaning  never  use  recovery  routes.  Recocery  routes 
refer  to  those  routes  which  contain  bases  where  an  aircraft  can  be  serviced  after  executing  a 
quick-tum  mission.  Recovery  policy  is  set  separately  for  each  supor  node.  Any  super  node 
containing  a  port  should  have  a  “norec”  policy  since  ships  would  not  be  required  to  execute 
quick  turn  missions.Scenario.inc  contains  the  data  for  on  load  time,  off  load  time  and  enroute 
recovery  and  maintenance  time.  Penalties  for  late  and  non-delivered  cargo,  as  well  as  rewards 
for  crew  rest  are  calculated  here.  In  addition,  shuttle  and  aerial  refueling  parameters  are 
contained  in  this  file. 

4.  Acdat.inc.  Acdat.inc  is  called  by  scenario.inc.  It  contains  aircraft  specific  data,  to  include; 
relative  size  (to  apply  to  MOG  considerations),  speed,  allowable  utilization  rate  and  the  rate  at 
which  aircraft  will  be  allocated  to  the  deployment.  In  addition,  this  file  scales  the  weights  of  the 
cargo  and  passengers  in  order  to  calculate  the  aircraft’s  “critical”  payload  at  each  range.  The 
file  also  includes  a  fuel  consumption  table,  which  contains  data  for  each  type  of  aircraft  used. 

5.  Calc.inc.  Calc.inc  is  also  called  by  scenario.inc.  This  file  contains  many  of  the  calculations 
that  are  needed  elsewhere  in  NRMO.  These  calculations  include;  utilization  hours,  distances 
and  flight  times  (including  ground  time),  fuel  consumption  rates  and  MOG  calculations. 
Calc.inc  contains  an  abort  function  that  will  abort  a  mission  that  cannot  be  completed  within  the 
allotted  time  of  the  deployment . 
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B.  OUTPUT  FILE 


The  output  file  is  divided  into  several  sections.  The  first  section  shows  the  value  of  the 
objective  function.  The  next  section  lists  the  number  of  missions  flown,  by  aircraft.  The  third 
section  displays  cargo  related  information.  This  includes  cargo  delivered  over  time  by  category 
of  aircraft  (military  or  CRAF),  undelivered  cargo  and  undelivered  PAX.  The  fourth  section 
concentrates  on  information  needed  for  base  analysis.  It  breaks  down  the  number  of  aircraft  per 
day  that  flow  through  a  base,  the  fuel  and  MOG  that  they  use  and  the  cargo  that  they  carry. 
The  final  section  summarizes  the  total  time,  flying  time  and  ground  time  spent  on  each  route.  In 
all  sections,  minimum,  maximum  and  mean  values  are  shown.  The  report  can  be  tailored  to 
display  any  information  desired. 
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APPENDIX  C  -  GLOSSARY  OF  ACRONYMS  /  DEFINITIONS 


AFM 

Airlift  Flow  Model 

AFSAA 

Air  Force  Studies  and  Analysis  Agency 

AF/XOM 

Air  Force  Chief  of  Staff  for  Mobility 

AMC 

Air  Mobility  Command 

Bulk 

Cargo  with  a  high  weight  to  volume  ratio.  Ex:  ammunition, 
palletized  cargo,  batteries,  etc. 

carrier 

generic  name  for  any  vehicle  that  conveys  cargo  or  pax 

carr_item 

Indicates  carrier  capacity  of  an  item.  Ex:  carr_bulk  is  how  much  bulk 
cargo  a  carrier  can  move. 

FDE 

Force  Deployment  Estimator 

GUI 

Graphic  User  Interface 

itemjmoved 

Indicates  the  amount  of  an  item  that  has  been  moved.  Ex.  bulk_moved 
is  how  much  bulk  cargo  has  been  moved. 

JCS 

Joint  Chiefs  of  Staff 

MOG 

Maximum  on  Ground 

MOM 

Mobility  Optimization  Model 

MRS  BURU 

Mobility  Requirements  Study  Bottoms  Up  Review 

MSC 

Military  Sealift  Command 

MTW 

Major  Theater  War 

NPS 

Naval  Postgraduate  School 

NRMO 

Naval  Postgraduate  School  /  RAND  Mobility  Optimizer 

Over 

Cargo  with  a  low  weight  to  volume  ratio.  Ex:  Trucks,  trailers,  etc. 

%Over 

Percent  of  cargo  that  is  oversized. 
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Out 


Cargo  that  will  only  fit  on  ships  or  wide  bodied  aircraft.  Ex:  tank, 
infantry  fighting  vehicle. 

%Out  Percent  of  cargo  that  is  outsized. 

Pax  Personnel.  In  FDE,  it  is  the  number  of  personnel  that  a  plane  can 

carry  while  carrying  cargo. 

PaxO  In  FDE,  the  number  of  personnel  a  plane  can  carry  if  carrying  no  cargo. 

quick  turn  Unloading  an  aircraft  in  theater  without  servicing.  Ships  will  not  execute 

quick  turn  missions. 

recovery  base  A  base  where  an  aircraft  can  receive  services  after  a  quick  turn  mission 

WAD  Warfighting  Analysis  Division 
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